Nachdem ein Apache keine Seiten mehr auslieferte und ein Neustart des Apaches immer mit der Fehlermeldung “no space left on device” abbrach, war guter Rat teuer. Ein
df -h
zeigte auf allen Mountpoints genügend Speicherplatz an. Nur ein Neustart half mir vorübergehend aus der Misere. Leider bot die betroffene Maschine noch andere essentielle Dienste an, sodass das keine dauerhafte Lösung sein konnte. Eine Recherche ergab, dass der Apache unter Umständen zu viele sogenannte Semaphoren-Arrays belegt. Bei einem erneuten Auftreten des Fehlers überprüfte ich das mit einem
ipcs -s | grep apache
Apache steht hier für den Benutzer, unter dem der Webserver betrieben wird. Damit bestätigte sich die oben genannte These. Um die nicht mehr benötigten Ressourcen zu löschen verwendete ich
ipcrm -s SemID
oder eleganter in einer Schleife:
for i in `ipcs -s | grep apache | awk {'print $2'}`; do ipcrm -s $i; done
Danach stand einem Neustart des Apaches nichts mehr im Weg.

Da es sich bei Axis2 um eine Neuentwicklung gegenüber der Vorgängerversion handelt, wurde ein komplett anderes Data Binding Konzept umgesetzt. Zum Einsatz kommen bestehende Lösungen wie:

• ADB, (http://ws.apache.org/axis2/1_0/adb/adb-howto.html)
• XMLBean, (http://xmlbeans.apache.org )
• JiBX, (http://jibx.sourceforge.net/ )
• JAXB-RI, (https://jaxb.dev.java.net/nonav/2.1.6/docs/vendorCustomizations.html )
• oder JaxME, (http://ws.apache.org/jaxme/ )

die in Axis2 integriert werden. XMLBeans stammen ursprünglich von BEA Systems und wird von Apache weiterentwickelt. XMLBeans heben den Informationsgehalt eines XML-Infosets während der Verarbeitung auf, so dass Metadaten zur Verfügung stehen, die bspw. für eine Schema-Validierung genutzt werden können. Wenn XMLBeans als Data Binging genutzt werden sollen, muss “-d xmlbeans” als Parameter angegeben werden. (Defaultwert ist ADB):

WSDL2JAVA ... -d xmlbeans meine.wsdl

Das Framework generiert für jeden benutzerdefinierten Datentyp eine Interfaceklasse, mit der man bei der Entwicklung in Berührung kommt. Alle Interfaces erben von XMLObject und erhalten eine interne statische Inner Class “Factory” mit der eine Klasse des jeweiligen Types erzeugt werden kann. Beispiel zur Erzeugung eines Objektes vom Typ Kunde:

KundeDocument kundeDoc = KundeDocument.Factory.newInstance();

Ein XML-Document kann über die Methode “save” in ein XML-Format serialisiert werden. Mit “xmlText” wird ein String als XML zurückgegeben.

String kundeXml = kundeDoc.xmlText();

kundeDoc.save(new File("kundeDoc.xml"));

Andere Data Bindings bilden Datantypen wie bspw. xsd:String, xsd:Token, xsd:anyUrl oder xsd:Name auf String ab. XMLBeans bietet hierfür eigene Datentypen, um die unterschiedlichen Wertebereiche und semantischen Bedeutung zu behalten.

Neuere Apache-Versionen unterstützen sogenannte Multidomainzertifikate. Damit ist es möglich, mehrere vhost mit nur einem SSL-Zertifikat, welches der Browser als gültig akzeptiert, abzusichern. Um jedoch ein Zertifikat von einer CA zu erhalten, müssen wir ein CSR (Certificate Signing Request) erzeugen. Mit openssl ist diese Aufgabe schnell erledigt. Wie kann man hier aber mehrere Domains angeben? Ein möglicher Weg kann die Erstellung eines CSRs mit mehreren CommonNames sein. Dazu editieren wir /etc/ssl/openssl.cnf. In der Sektion [ req_distinguished_name ] ändern wir den Eintrag:

commonName = Common Name (eg, YOUR name)
commonName_max = 64

in:

0.commonName = Common Name 1 (eg, YOUR name)
0.commonName_max = 64

1.commonName = Common Name 2 (eg, YOUR name)
1.commonName_max = 64
.
.
.
um. Mit einem 0.commonName_default=www.domain.tld kann man auch gleich einen passsenden Standardwert einstellen. Zum Schluß generieren wir uns den Schlüssel mit 2048 bits und den CSR:

openssl req -new -nodes -keyout dateiname.key -out dateiname.csr -newkey rsa:2048

Weitere mögliche Wege gehen über “subjectAltName” oder über “commonName” und “subjectAltName”.

Betreibt man einen Apache als Reverse Proxy, so hat man im Allgemeinen das Problem, dass alle
Zugriffe auf dem Backend-Apache als Zugriffe des Frontends geloggt werden. Damit ist es
praktisch unmöglich eine vernünftige Statistik zu erstellen.
Abhilfe schafft hier das rpaf-Modul (reverse proxy add forward). Dieses Modul kann die für andere
Apache-Module sichtbare Remoteadresse ändern. Installiert wird das Modul auf dem Backend. Die
Konfiguration gestaltet sich sehr einfach:

LoadModule rpaf_module mod_rpaf.so
RPAFenable On
RPAFsethostname On
RPAFproxy_ips 127.0.0.1 192.168.1.2

Zuerst wird das Modul geladen und eingeschalten.Mit RPAFsethostname werden die selben
Hostnamen wie auf dem Frontend verwendet. Zum Schluß werden die Frontends definiert. Der
Vollständigkeithalber die letzte Direktive:

RPAFheader X-Forwarded-For #wählt Header X-Forwarded-For oder X-Real-IP

Das Webservice Framework Axis2 von Apache steht seit 2005 in der Version 2 zur Verfügung und bietet einige Vorteile gegenüber der Vorgängerversion. Aus meiner Sicht sind es vor allem Performance Steigerung, höhere Flexibilität beim Deployment von Services und eine verbesserte Unterstützung von aktuellen Standards, die einen Einsatz von Axis2 sinnvoll macht.

Anhand eines Beispieles soll im Folgenden schrittweise gezeigt werden, wie eine einfache Axis2 Anwendung mit Eclipse und Web Tools Platform 2.0.1 entwickelt werden kann.

Für dieses Beispiel wird benötigt:

1. WTP in Version 2.0.1 (http://www.eclipse.org/webtools)
2. Tomcat 5.5 (http://tomcat.apache.org)
3. AXIS2 Framework 1.2 als Standard Binary Distribution (http://ws.apache.org/axis2/download.cgi)

Vorbereitung im Eclipse:

1. Tomcat einbinden (Preferences > Server > Installed Runtimes)
2. Axis2 einbinden (Preferences > Webservices > Axis2 Preferences > Axis2 Runtime Location)

Erstellen einer Anwendung

1. Neues DynamicWeb-Projekt anlegen und Axis2 Funktionalität einbinden (File -> New -> Other… -> Web -> DynamicWeb Project)

    

   

2. Eigene Serviceklasse erstellen und implementieren. (File -> New -> Class) Beispiel:

    

   

3. Webservice erstellen (File -> New -> Other… -> Web Services -> Web Service) . Im Wizard die Serviceklasse auswählen und Webservice Type: „ Bottom up Java bean Web Service“; Server: „Tomcat v5.5 Server“ ; WICHTIG Web Service Runtime: „Apache Axis2″. Optional kann ein Testclient erstellt werden.

   

4. Service.xml erzeugen lassen oder eine Vorhandene einbinden
5. Server starten, Anwendung deployen und testen. Unter “http://localhost:8080/WebserviceTest/” steht dann eine Administrationsoberfläche von Apache zur Verfügung, auf der alle Services aufgelistet sind.
6. Optional kann ein Testclient erstellt werden. (New > ohter > Web Services > Web Service Client)

Link Tipp: Eclipse Plug-In zur Codegenerierung für Axis2 (http://ws.apache.org/axis2/tools/1_2/eclipse/wsdl2java-plugin.html)

Um in einer Webanwendung sicherzustellen, dass die Nutzer keinen Viren oder andere Schädlinge durch Uploads einschleusen, gibt es verschieden Möglichkeiten. Eine Möglichkeit ist es, in der Webanwendung selbst eine Virenüberprüfung anzustossen. Eine Alternative ist es, die Virenprüfung in einem vorgeschaltenem Apache vorzunehmen.

Diese Funktionalität kann mit dem Modul ModSecurity für den Apache erreicht werden. Dieses erkennt bei einem Request des Clients mitgesendete Dateien. Durch bestimmte Filterregeln kann ModSecurity so konfiguiert werden, dass ein Script auf dem Server aufgerufen wird:

SecRule FILES_TMPNAMES "@inspectFile /usr/local/share/clamav/modsecurity-clamav.pl" t:none,redirect:'%{REQUEST_FILENAME}?error=virus'

Diese Regel bewirkt, dass jede mitgesendete Datei auf der Festplatte zwischengespeichert wird, und das Script ausgeführt wird. Das Script selbst wiederrum ruft den Virenscanner auf, und parst das Ergebnis. Je nach dem ob ein Virus erkannt wird, wird ‘0′ oder ‘1′ zurückgegeben. Wenn kein Virus gefunden wurde, wird der Request wie gewohnt fortgesetzt. Im Fehlerfall wird eine definierte Aktion ausgeführt, wie z. B. die Weiterleitung zu einer Fehlerseite, die dem Nutzer eine Fehlermeldung ausgibt. In dem Beispiel wird ein Redirect mit der Request URL und einem Parameter error=virus zum Client gesendet.

Als Virenscanner empfiehlt sich der OpenSource Virenscanner ClamAV der für verschiedenste Systeme zur Verfügung steht. Das bereits oben beschrieben Script modsecurity-clamav.pl übernimmt den Aufruf und das Parsen des Scanneoutputs. Ein Beispiel Script findet sich hier.

Wenn noch keine Apache vorhanden ist, muss dieser als Reverse Proxy konfiguriert werden. Anfragen an den Apache müssen dabei an die eigentliche Webanwendung weitergeleitet werden. Zusätzlich muss ein URL Rewriting der Webanwendungsresponse stattfinden. Dies ist z. B. hier beschrieben.