Tutorial

Installation der SAP-DB mit ODBC Unterstützung für PHP und Apache unter Linux

A rough english translation for this tutorial is available here.

Im folgenden Tutorial soll Schritt-für-Schritt erklärt werden, wie man unter Linux die OpenSource Datenbank von SAP installiert und ganz nebenbei auch noch mit PHP auf die darin abgelegten Daten zugreifen kann. Als Grundlage für diese Anleitung wird vorausgesetzt, dass ein gängiges Linux-System bereits vorinstalliert ist. Dieses Tutorial wurde von mir unter SuSE 7.1 mit Kernel 2.4 erprobt. Sofern nicht anders angegeben, wurden alle Installationsarbeiten als Benutzer "root" durchgeführt.

Schritt 1: Dateien herunterladen - alles was man so braucht!

Wie bereits in der Einleitung erwähnt, soll es in diesem Tutorial um Linux, die SAP-DB, PHP und ODBC gehen. Um PHP benutzen zu können, muss natürlich auch noch ein Webserver her - unter Linux heisst das, wir brauchen auch noch den "Apache". Im folgenden werde ich zu jedem benötigtem Softwarepaket eine kurze Erläuterung, einen Verweis auf die Homepage des Produkts und einen Link auf die von mir verwendete Datei abgeben. Sollte im Laufe der Zeit der ein oder andere Link verwaisen, bitte ich das zu entschuldigen.

Linux:

Eine gängige Linux-Distribution können sich normale Menschen natürlich nicht herunterladen... gehen Sie daher in einen Laden und kaufen Sie sich für knapp 100 DM das Linux Ihrer Wahl (z.B. RedHat oder SuSE).
Achten Sie bei der anschliessenden Installation des Betriebssystems darauf, dass die Pakete "flex" und "bison" installiert sind. Ausserdem sollte der Apache-Webserver nicht(!) installiert werden - das werden wir im Laufe des Tutorials noch nachholen.

SAP-DB:

Die Opensource Datenbank SAP-DB ist das Kernstück in diesem Tutorial. Neben der eigentlichen Datenbank, dem Webinterface und einigen Ergänzungsprogrammen brauchen wir auch noch einen speziellen ODBC-Treiber, den wir ebenfalls bei SAP erhalten. Da es für gewöhnlich wesentlich einfacher ist, RPM Pakete zu installieren anstatt den Quellcode neu zu kompilieren, werde ich soweit es sinnvoll ist, RPMs bevorzugen.

Homepage: www.sapdb.org
Dateien: ftp://ftp.sap.com/pub/sapdb/bin/linux/sapdb-srv-7.3.0.8-1.i386.rpm
ftp://ftp.sap.com/pub/sapdb/bin/linux/sapdb-ind-7.3.0.8-1.i386.rpm
ftp://ftp.sap.com/pub/sapdb/bin/linux/sapdb-web-7.3.0.8-1.i386.rpm
ftp://ftp.sap.com/pub/sapdb/bin/linux/sapdb-callif-7.3.0.8-1.i386.rpm

Apache:

Bevor wir über PHP und ODBC auf die SAP-DB zugreifen können, brauchen wir natürlich auch einen Webserver, der mit PHP zusammenarbeiten kann. Da wir im späteren Verlauf des Tutorials PHP "selber bauen" müssen, werden wir auch den Apache selbst kompilieren. Dies scheint mir deshalb geboten, da ich die Erfahrung gemacht habe, dass zumindest die SuSE Version des Apache nicht mit meiner selbstkompilierten PHP Variante zurecht kommen wollte.

Homepage: www.apache.org
Datei: http://httpd.apache.org/dist/httpd/apache_1.3.20.tar.gz

PHP

Die Skriptsprache PHP muss explizit auf die SAP-DB-ODBC-Schnittstelle ausgerichtet werden. Daraus ergibt sich, dass wir abermals auf den Quellcode zurückgreifen müssen. Um sich unnötigen Ärger während des Tutorials zu ersparen, sollte man die hier empfohlene (oder höhere) Version von PHP4 nehmen. Wer unbedingt auf ältere Quellen zurückgreifen muss (oder möchte), sollte zumindest PHP4.0.3 benutzen. Noch ältere PHP-Versionen können meines Wissens nicht auf die SAP-DB zugreifen - unabhängig davon, welche Tricks man beim kompilieren benutzt.

Homepage: www.php.net
Datei: http://www.php3.de/distributions/php-4.0.5.tar.gz

OpenSSL & mod-ssl

Wer eine derart mächtige Datenbank wie die SAP-DB installiert und diese ganz nebenbei über PHP bearbeitet, wird dies vermutlich nicht nur Spass an der Freude machen. Um professionellen Ansprüchen zu genügen, werde ich daher auch kurz aufzeigen, wie man den Apache Webserver SSL-fähig macht. Derart gesichert sollte es kein Problem sein, auch (sensible) Produktionsdaten aus der Datenbank an einem Browser weiterzuleiten.

Homepage: http://www.openssl.org
Datei: http://www.openssl.org/source/openssl-0.9.6a.tar.gz

Homepage: http://www.modssl.org
Datei: http://www.modssl.org/source/mod_ssl-2.8.4-1.3.20.tar.gz

Schritt 2: Installation der Datenbank

Auf geht's, nehmen wir uns die Datenbank vor. Wenn Sie im Schritt 1 alles erledigt haben, sollten auf Ihrem Linux System folgende (bzw. aktuellere) Dateien vorhanden sein: Die Dateien werden nun in dieser Reihenfolge installiert. Da es sich um RPM-Pakete handelt, ist die Installation denkbar einfach.
rpm -i sapdb-ind-7.3.0.8-1.i386.rpm

rpm -i sapdb-srv-7.3.0.8-1.i386.rpm

rpm -i sapdb-web-7.3.0.8-1.i386.rpm

rpm -i sapdb-testdb-7.3.0.8-1.i386.rpm

rpm -i sapdb-callif.7.3.0.8-1.i386.rpm

Was ist nun alles passiert? Im Verzeichnis /opt/sapdb findet man nun die installierten Dateien. Ausserdem wurde im System der Benutzer "sapdb" angelegt, der standardmässig das Passwort "sapdb" hat. Aus Sicherheitsgründen sollte dies am Ende der Installation geändert werden.

Schritt 3: Die Datenbank im System verankern

Die meisten Benutzer werden sicherlich keine Lust haben, nach jedem Systemstart die Datenbank "per Hand" neu zu starten.

SuSE Benutzer sollten folgende Zeile in der Datei /etc/rc.config ergänzen:

START_SAPDB=yes
Nachdem die Zeile eingefügt wurde, muss das System mit dem Befehl
SuSEconfig
aktualisiert werden.

Nun müssen noch einige symbolische Links gesetzt werden, damit die Datenbank auch gestartet werden kann.

cd /etc/init.d

ln -s ../init.d/sapdb rc2.d/S45sapdb

ln -s ../init.d/sapdb rc2.d/K45sapdb

ln -s ../init.d/sapdb rc3.d/S45sapdb

ln -s ../init.d/sapdb rc3.d/K45sapdb

Durch die S-Links wird sichergestellt, dass die Datenbank in den Runlevels 2 (Terminalmodus) und 3 (Grafikmodus) gestartet wird. Die K-Links sorgen dafür, dass die Datenbank beim herunterfahren des Systems "ordentlich" beendet wird.

Schritt 4: Shell konfigurieren, neu booten und Pause machen

Damit wir in Zukunft die Skripte der SAP-DB vernünftig ansprechen können, müssen zunächst noch einige Pfade vorkonfiguriert werden. Die folgenden Einträge ergänzen Sie bitte in der Datei /root/.bash_profile (wenn die Datei nicht vorhanden ist, muss sie einfach neu angelegt werden):
SAPDBROOT=/opt/sapdb

PATH=$PATH:$SAPDBROOT/indep_prog/bin

. /opt/sapdb/indep_prog/demo/FirstSteps/sapdbenv.sh >/dev/null

export LD_LIBRARY_PATH=/opt/sapdb/web/lib

Soviel zur Konfiguration der Bash - weiter gehts mit dem Test des Datenbankservers. Starten Sie die Datenbank mit dem Befehl

/etc/init.d/sapdb start

Wenn es keine Probleme gab, antwortet der Server nun mit "Starting sapdb services: INFO 10004: Vserver started". Sollte diese Meldung nicht erscheinen, überprüfen Sie die Schritte 3 und 4.
Sobald die Datenbank ohne Fehlermeldung anläuft, kann der Reboot ohne Sorge durchgeführt werden. Natürlich hört man immer wieder, dass man Linux/Unix-Systeme eigentlich nur nach einem Stromausfall neu booten muss. Trotzdem ist ein Neustart nun angebracht, da auf diese Weise die Startskripte für das Anlaufen der Datenbank sorgen und man gleichzeitig sicherstellen kann, dass bis hierhin alles funktioniert. Der Neustart sollte ausserdem zu einer kurzen Pause genutzt werden, denn der wirklich fehleranfällige Teil beginnt erst noch.

Schritt 5: Anlegen der Testdatenbank

Damit es zu keinen Missverständnissen kommt, soll an dieser Stelle zunächst erstmal der Unterschied zwischen der SAP-DB und der Testdatenbank erläutert werden. Vereinfach ausgedrückt kann man sagen, dass die SAP-DB das Hauptprogramm ist, über die alle untergeordneten Datenbanken (wie z.B. auch die Testdatenbank) angesprochen werden. Auf diese Weise können ohne Probleme viele unterschiedliche Datenbanken innerhalb der SAP-DB benutzt und verwaltet werden.

Die folgenden Schritte führen Sie bitte als Benutzer "sapdb" aus:

cd /opt/sapdb/indep_prog/demo/Firststeps

. sapdbenv.sh

cd /opt/sapdb/testdb

./create_demo_db.sh

Mit etwas Glück führt das System nun ein Skript aus, an dessen Ende die Datenbank TST innerhalb der SAP-DB angelegt wurde.
Sollte irgendetwas nicht so aussehen, als wäre es erfolgreich beendet worden, lesen Sie einfach weiter - ansonsten fahren Sie mit dem nächsten Schritt fort.

Folgende Probleme sind dem Verfasser bekannt:

Schritt 6: Die Testdatenbank starten

Das "create_database" Skript hat im vergangenen Schritt dafür gesorgt, dass eine Datenbank namens TST angelegt wurde. Diese Datenbank existiert nun zwar, ist aber noch nicht aktiviert. Genau wie die SAP-DB muss auch jede untergeordnete Datenbank nach(!) dem Start der SAP-DB aktiviert werden. Dies geschieht mit folgenden Befehlen:

/opt/sapdb/indep_prog/bin/dbmcli -d TST -u dbm,dbm db_cold

/opt/sapdb/indep_prog/bin/dbmcli -d TST -u dbm,dbm db_warm

Mit diesem Aufruf wird die Datenbank TST gestartet. Da für gewöhnlich nicht irgendein Datenbankbenutzer die Datenbank an- und ausschalten kann, muss mit dem Parameter -u ein Benutzername ("dbm") nebst Passwort (auch "dbm") angegeben werden. Der Befehlsaufruf endet anschliessend mit der Bestimmung des Datenbankstatus. Zuerst wird die Datenbank auf "kalt" gesetzt - anschliessend auf warm. Im "warm"-Level ist die Datenbank für normale Benutzer zugänglich, d.h. produktiv.

Vorsicht: Beachten Sie unbedingt das der Benutzername und das Passwort nur durch ein Komma voneinander getrennt sind. Anführungszeichen, Leerzeichen oder sonstige Trennungen sind hier nicht angebracht und führen zu Fehlern. Ausserdem hat sich im "start_testdb.sh" Skript von SAP eine merkwürdige Eigenheit eingeschlichen. Die TST-Datenbank wird nach dem Aufruf des Startskripts nur auf "db_cold" gesetzt. Die Datenbank kann so nicht benutzt werden - sie muss erst mit dem zweiten Befehl in diesem Schritt auf "db_warm" gesetzt werden.

Um die Datenbank beim hochfahren des Rechners automatisch zu starten, können Sie die beiden Befehle ganz leicht in das Start-Stop-Skript der SAP-DB integrieren. Ergänzen Sie dazu einfach die folgenden Zeilen in der Datei /etc/init.d/sapdb:

RETVAL=1
case "$1" in
    start)
        echo -n "Starting sapdb services: "
        if [ ! -z "$X_SERVER" ]; then
            $X_SERVER start
            RETVAL=0

        fi
        touch /var/lock/subsys/sapdb

        # Fügen Sie die folgenden beiden Zeilen ein

        /opt/sapdb/indep_prog/bin/dbmcli -d TST -u dbm,dbm db_cold
        /opt/sapdb/indep_prog/bin/dbmcli -d TST -u dmb,dmb db_warm
        ;;
    stop)
        echo -n "Shutting down sapdb services: "
        if [ ! -z "$X_SERVER" ]; then

            # Fügen Sie die folgenden beiden Zeilen ebenfalls ein
            /opt/sapdb/indep_prog/bin/dbmcli -d TST -u dmb,dmb db_cold
            /opt/sapdb/indep_prog/bin/dbmcli -d TST -u dmb,dmb db_offline -immediate
            # Achtung! Durch den Parameter -immediate werden alle laufenden Transaktionen abgebrochen.
            # Dies wird deshalb gemacht, da dieser Teil des Skripts immer nur beim herunterfahren des Systems
            # aufgerufen wird. D.h., das Betriebssystem wartet nicht(!) darauf, dass die SAP-DB von sich aus
            # fertig wird. Es ist also besser, im Notfall eine Transaktion zu verlieren als Schaeden an der
            # gesamten Datenbank in Kauf zu nehmen.

            $X_SERVER stop
            RETVAL=0
        fi
        rm -f /var/lock/subsys/sapdb
        ;;
    status)
        [...]

Schritt 7: Ein kleiner Exkurs ins SAP-DB Webinterface

SAP liefert von Haus aus einen eigenen kleinen Webserver mit, mit dem die SAP-DB administriert werden kann. Alternativ zum eigenen Webserver von SAP kann die SAP-DB auch mittels CGI und Apache bearbeitet werden. Da in meiner Systemumgebung der "Administrations-Webserver" nur dann gestartet wird, wenn er auch wirklich benötigt wird, beschränke ich mich im folgenden auf die Verwendung des SAP-Webservers.
Da der Webserver schon installiert ist (s. Schritt 2), brauchen wir ihn nun nur noch zu starten. Benutzen Sie dazu die folgenden Befehle:
cd /opt/sapdb/web/pgm/ wahttp&
Im Terminal sollte nun eine Liste von Prozessen durchlaufen - und das ist auch gut so. Sobald die Prozessliste zum Stillstand gekommen ist, können Sie mit einem normalen Browser auf Port 9999 Ihres Linux-Rechners zugreifen. Probieren Sie nun die folgenden URLs aus:
http://<Linuxrechnername>:9999/webdbm

http://<Linuxrechnername>:9999/websql

Die erste URL führt Sie zur Administrationsoberfläche der SAP-DB. Hier können Sie untergeordnete Datenbanken (wie z.B. TST) per Mausklick starten und stoppen, neue Datenbanken anlegen, usw. Bevor Sie vollen Zugriff auf die Möglichkeiten des Webinterfaces bekommen, müssen Sie sich zunächst als Datenbankadministrator einloggen. Als Benutzername verwenden Sie bitte "dba" und als Passwort ebenfalls "dba". Diese Benutzer wurden von der Installationsroutine standardmässig eingerichtet und sollten nach Abschluss des Tutorials geändert werden. Sollte der Login mit diesen Daten nicht funktionieren, probieren Sie einfach mal als Benutzernamen "dbm" und als Passwort ebenfalls "dbm".

Schritt 8: Die Testdatenbank mit ein paar Daten anreichern

Um einen ersten Eindruck vom WebSQL-Interface zu bekommen, wird in diesem Schritt innerhalb der Testdatenbank (TST) eine Tabelle mit ein paar Daten angelegt. Um das WebSQL-Interface nutzen zu können, muss der SAP-Webserver gestartet sein (s. vorigen Schritt).
Gehen Sie nun mit Ihrem Browser auf die URL
http://<Linuxrechnername>:9999/websql
Bevor Sie mit der Arbeit beginnen können, müssen Sie sich natürlich abermals einloggen. Als Datenbankname nehmen Sie "TST", als Benutzername "dba" und als Passwort geben Sie "dba" an.
Geben Sie nun im Eingabefeld die folgenden Befehle an - und bestätigen Sie sie jeweils mit dem Button "Execute":
create table customer ( cust_id fixed(4) key , name char(12), firstname char(12) )
insert into customer values (1,'Ditze','Andreas')

insert into customer values (2,'Walter','Andreas')

In der Datenbank sind nun zwei Datensätze eingetragen - und können über den Befehl
select * from customer
angezeigt werden. Sollte bis hierhin alles geglückt sein, werden wir uns nun dem Thema Apache und PHP widmen.

Schritt 9: Auspacken der .tar.gz Pakete

Nachdem die SAP-DB soweit einsatzbereit ist und erste Testdatensätze bereitgestellt wurden, können wir uns mit dem Webserver befassen, über den mittels PHP und ODBC auf die Datenbank zugegeriffen werden soll.
Bevor mit der Konfiguration und Kompilierung der Softwarepakete begonnen werden kann, müssen diese natürlich erstmal ausgepackt werden. Im folgenden gehe ich davon aus, dass neben Apache und PHP auch das SSL-Modul für den Webserver eingefügt werden soll.
mkdir /usr/src/laps

mkdir /usr/src/laps/tarballs

mv apache_1.3.20.tar.gz /usr/src/laps/tarballs

mv mod_ssl-2.8.4-1.3.20.tar.gz /usr/src/laps/tarballs

mv openssl-0.9.6a.tar.gz /usr/src/laps/tarballs

mv php-4.0.5.tar.gz /usr/src/laps/tarballs

cd /usr/src/laps

tar -xzf tarballs/openssl-0.9.6a.tar.gz

tar -xzf tarballs/php-4.0.5.tar.gz

tar -xzf tarballs/mod_ssl-2.8.4-1.3.20.tar.gz

tar -xzf apache_1.3.20.tar.gz

Was haben diese Befehle bewirkt? Zunächst wurden zwei Verzeichnisse angelegt, nämlichs laps (Linux-Apache-PHP-SAPDB) und laps/tarballs (Tarballs ist das Verzeichnis, in dem die .tar.gz Pakete aufbewahrt werden). Anschliessend wurden die in Schritt 1 heruntergeladenen Softwarepakete in das "tarballs" Verzeichnis verschoben. Achten Sie darauf, dass Sie, bevor Sie die vier "mv" Befehle eingeben, sich auch in dem Verzeichnis befinden, in dem die Dateien abgelegt wurden.

Schritt 10: Vorbereiten des SSL-Moduls

Da das Open-SSL Modul die Grundlage für das Programm mod_ssl ist, müssen wir natürlich mit der Erstellung dieses Moduls anfangen. Starten Sie daher den Kompilierungs-Marathon mit folgenden Befehlen:
cd /usr/src/laps/openssl-0.9.6a

./config --prefix=/usr/local/openssl/0.9.6a

 make

 make test

 make install

 ln -s /usr/local/openssl/0.9.6a /usr/local/openssl/current

Sollten alle Befehle korrekt abgearbeitet worden sein, sollte das Open-SSL Modul nun im Verzeichnis /usr/local/openssl/0.9.6a zu finden sein. Um spätere Updates dieses Moduls nicht unnötig zu erschweren, wurde das Verzeichnis /usr/local/openssl/0.9.6a mit dem Verzeichnis /usr/local/openssl/current verbunden. Dies ist deshalb sinnvoll, weil alle Programme, die auf Open-SSL zugreifen, anschliessend so konfiguriert werden, dass sie das Open-SSL Modul im "current" Verzeichnis suchen. Sollte also irgendwann mal eine neuere Version vom Open-SSL ins System integriert werden, muss lediglich der soeben angelegt symbolische Link aufgelöst und durch einen neuen Link (zur aktualisierten Open-SSL Version) ersetzt werden.

Schritt 11: Bau des Apache Webservers

Diese Version des Apache wird als DSO-Version gebaut. DSO heisst, dass der Server modular arbeiten kann - d.h., einzelne Module können jederzeit ausgetauscht werden ohne das der Server jedesmal neu kompiliert werden muss. Eines der Module, was hierfür in betracht kommen könnte, ist sicherlich PHP - allerdings soll das Thema DSO hier nicht vertieft werden.
cd /usr/src/laps/mod_ssl-2.8.4-1.3.20

./configure --with-apache=../apache_1.3.20 --with-ssl=../openssl-0.9.6a --prefix=/usr/local/apache/1.3.20 --datadir=/usr/local/apache/htdocs --enable-module=so  --enable-shared=max --enable-module=ssl

Achten Sie bei der Eingabe des "./configure"-Befehls darauf, das der komplette Befehlsaufruf in einem Stück abgegeben werden muss. Auch sind die Leerzeichen penibel einzuhalten. Ergänzen Sie keine Leerzeichen und lassen Sie auch keine weg - der Compiler ist in dieser Beziehung alles andere als Tolerant.
Sollte das "./configure"-Skript fehlerfrei durchgelaufen sein, kann der Webserver nun "gebaut" werden. Verwenden Sie dazu diese beiden Kommandos:
cd /usr/src/laps/apache_1.3.20

make

Schritt 12: Ein SSL-Zertifikat bereitstellen

Damit der Webserver auch tatsächlich SSL-Verbindungen bereitstellen kann, muss nun noch ein entsprechendes Zertifikat (vergleichbar einem Schlüssel) generiert werden. Die in diesem Zertifikat hinterlegten Daten können von den Benutzern des Webservers eingesehen werden. Die Angaben sollten also dem vorgesehenem Arbeitsumfeld entsprechen und nicht allzu fantasievoll ausgefüllt werden. Beginnen wir mit der Erstellung eines CA (Certification Authority) Zertifikat:
make certificate TYPE=custom
Der Make-Befehl fragt nun nach den Informationen, die Ihr Zertifikat tragen soll - tragen Sie hier Ihre(!) Daten ein:
Signature Algorithm: R

Country Name: "DE"

State or Province: "Hessen"

Localty Name: "Giessen"

Organization Name: "Fachhochschule Giessen-Friedberg"

Organizational Unit Name: "TR-CA"

Common Name: "Technische Redaktion-CA"

Email Address: "andreas.ditze@gmx.de"

Certificate Validity: "365"

Certificate Version: 3

Nun wird das "eigentliche" Zertifikat des Webservers erstellt:
Country Name: "DE"

State or Province: "Hessen"

Localty Name: "Giessen"

Organization Name: "Fachhochschule Giessen-Friedberg"

Organizational Unit Name: "Technische Redaktion"

Der Zertifikatserstellungsprozess ist nun fast geschafft - es fehlt nur noch die Angabe des Namens, unter dem der Rechner später über SSL erreichbar sein soll:
Common Name: "rechnername.mni.fh-giessen.de"

Email Address: "andreas.ditze@gmx.de"

Certificate Validity: "365"

Certificate Version: 3

Zum Schluss muss nun noch festgelegt werden, ob das CA- und das Webserverzertifikat lokal verschlüsselt werden soll - oder nicht. Die Unterschiede sind schnell erklärt. Sind die Files verschlüsselt, muss bei jedem Neustart des Apache ein Passwort eingegeben werden, bevor SSL-Verschlüsselungen möglich sind. Bei nicht verschlüsselten Passwörtern entfällt dies. Ein Produktionssystem sollte natürlich "eigentlich" mit verschlüsselten Passwörtern arbeiten - wer jedoch den Administrationsaufwand gering halten will (oder muss), wird wahrscheinlich die unverschlüsselte Variante wählen.

Schritt 13: Apache installieren und Pause einlegen

Nachdem der Apache nebst SSL konfiguriert ist, wird es nun Zeit, den Webserver im System zu verankern.
make install
Wie in Schritt 10 bereits erläutert, wird auch der Apache "symbolisch verlinkt" mit dem "/usr/local/apache/current" Verzeichnis. In diesem Fall hat es den sehr handfesten Vorteil, dass alle Einträge in der httpd.conf Datei (der zentralen Konfigurationsdatei des Apache) nur auf das "current"-Verzeichnis verweisen. Dadurch wird sichergestellt, dass neuere Versionen des Apache jederzeit eingesetzt werden können - und die "alte" Konfigurationsdatei weiterhin vewendet werden kann. Um für etwas Übersicht im System zu sorgen, wird anschliessend die Konfigurationsdatei als symbolischer Link im /etc Verzeichnis hinterlegt - dort sollten sich bekanntermaßen alle wichtigen Dateien dieser Art befinden.
ln -s /usr/local/apache/1.3.20 /usr/local/apache/current

ln -s /usr/local/apache/current/httpd.conf /etc/httpd.conf

Nachdem Sie das alles hinter sich gebracht haben, sollten Sie erstmal eine kleine Pause einlegen, bevor wir uns gleich dem Thema PHP widmen.

Schritt 14: PHP kompilieren

Nun gilt es, PHP so zu konfigurieren, dass wir ohne Probleme auf die SAP-DB zugreifen können:
cd /usr/src/laps/php-4.0.5

./configure --with-apxs=/usr/local/apache/current/bin/apxs --with-ftp --enable-versioning --enable-tracking-vars=yes --enable-url-includes --enable-sysvshm=yes --enable-sysvsem=yes --with-config-file-path=/etc --without-mysql --with-sapdb=/opt/sapdb/interface/odbc

make

Wie bereits in Schritt 11 erwähnt, habe ich mich auch diesmal darum bemüht, meiner Ansicht nach überflüssige Features gar nicht erst in den PHP Kernel zu integrieren. Dies zeigt sich insbesondere in der expliziten Anweisung den mysql Support auszusparen. Einzige Ausnahme stelllt in diesem Fall der FTP Support dar, den zwar sicherlich nicht jeder SAP-DB-PHP-Entwickler benötigt - ich jedoch wollte ihn mir für mein System offenhalten.

Schritt 15: PHP installieren

Nun können die PHP-Binärdateien im System hinterlegt werden. Anschliessend muss noch die PHP-Konfigurationsdatei in das Verzeichnis /etc kopiert werden.
make install

cp /usr/src/laps/php-4.0.5/php.ini-dist /etc/php.ini

Schritt 16: Start- und Stoppskripte des Apache einrichten

Obwohl der Webserver schon intensiv bearbeitet wurde, müssen noch einige Details erledigt werden. Dazu gehört u.a. die Einrichtung automatischer Start-Stop-Prozeduren und etwas Feintuning des Apache-Startskriptes. Als erstes sollten die Dateirechte des Apache-Servers so gesetzt werden, dass er nur vom Benutzer "root" gestartet und beendet werden kann.
chmod 700 /usr/local/apache/current/bin/apachectl
Wie unter Schritt 3 schon einmal beschrieben, werden nun einige symbolische Links erzeugt, um den Server beim Hochfahren des Systems automatisch zu starten.
ln -s /usr/local/apache/current/bin/apachectl /etc/rc.d/init.d/apachectl
Benutzer von SuSE-Distributionen sollten nun folgende Links anlegen:

cd /etc/init.d/rc2.d

ln -s ../apachectl S20apachectl

ln -s ../apachectl K20apachectl

cd /etc/init.d/rc3.d

ln -s ../apachectl S20apachectl

ln -s ../apachectl K20apachectl

Benutzer von RedHat-Distributionen sollten hingegen diese Links benutzen:

cd /etc/init.d/rc2.d

ln -s ../apachectl S20apachectl

cd /etc/init.d/rc3.d

ln -s ../apachectl S20apachectl

cd /etc/init.d/rc5.d

ln -s ../apachectl S20apachectl

cd /etc/init.d/rc0.d

ln -s ../apachectl K20apachectl

cd /etc/init.d/rc6.d

ln -s ../apachectl K20apachectl

Sollte auf diesem System schonmal ein Apache-Webserver installiert gewesen sein, versichern Sie sich, dass er nicht versehentlich ein zweites Mal gestartet wird. Schauen Sie dazu einfach mal in die Verzeichnisse rc2.d und rc3.d herein und suchen nach symbolischen Links, die neben den eben angelegten ebenfalls den Apache aufrufen (z.B. "S20apache oder K20apache"). Sollten Sie solche Links gefunden haben, löschen Sie sie mit dem Befehl
rm S20apache

rm K20apache

Schritt 17: SSL Standardmässig starten

Nun müssen wir noch ein Detail im Startskript des Apache untersuchen. Standardmässig startet der Apache, wenn man ihn mit dem Befehl "apachectl start" aufruft, nur den "normalen" HTTP Server. Damit gleichzeitig das HTTPS (d.h. SSL) Protokoll unterstützt wird, muss Apache mit dem Befehl "apachectl sslstart" aufgerufen werden. Ärgerlicherweise arbeiten die automatischen Start-Stop-Skripte immer nur mit den Befehlen "start" und "stop" - d.h., bei einem normal hochgefahrenen System würde der SSL Server niemals automatisch starten. Der Trick besteht nun darin, dass "apachectl"-Skript etwas abzuändern. Suchen Sie zunächst in der Datei /etc/init.d/apachectl nach folgenden Zeilen:
start)
if [ $RUNNING -eq 1 ]; then
echo "$0 $ARG: httpd (pid $PID) already running"
continue
fi
if $HTTPD ; then
echo "$0 $ARG: httpd started"
else
echo "$0 $ARG: httpd could not be started"
ERROR=3
fi
;;
 Nun ersetzen Sie die Zeile
$HTTPD ; then
durch den Aufruf
if $HTTPD -DSSL; then
Nun wird der SSL-Server standardmässig gestartet - womit nun eigentlich fast alles erreicht wurde.

Schritt 18: Ein Blick in die Apache-Konfigurationsdatei

Nachdem nun alle tückischen Klippen umschifft wurden, gilt es nun, noch einen Blick auf die Apache-Konfigurationsdatei /usr/local/apache/current/conf/httpd.conf zu werfen. Neben den "normalen" Konfigurationsoptionen (Port, Servername, Verzeichnisse) muss dort auch eingestellt werden, was mit PHP Dateien passieren soll. Damit sie vom Webserver richtig interpretiert werden können, suchen Sie nach der Zeile
#AddType application/x-httpd-php .php
und entfernen Sie das Kommentarzeichen ("#"). Falls Sie planen, den Apache in absehbarer Zeit einem Update zu unterziehen, sollten Sie die Gelegenheit nutzen und alle Verzeichnisangaben von "/usr/local/apache/1.3.20" auf "/usr/local/apache/current" umzustellen.
Suchen Sie nun noch nach folgenden Einträgen in der Konfigurationsdatei:
user nobody
group nogroup
Ersetzen Sie den Eintrag "user nobody" durch den Eintrag
user sapdb
Zum Hintergrund dieser Umstellung: Als "User" muss ein im System vorhandener Benutzer angegeben werden, der zumindest ein eigenes Heimatverzeichnis (/home/<username>) besitzt. In diesem Heimatverzeichnis muss sich die Datei ".odbc.ini" finden, die im nächsten Schritt angelegt wird. Unter sicherheitskritischen Aspekten ist diese Umstellung nicht ganz unbedenklich und in einer Produktionsumgebung sind an dieser Stelle sicherlich zusätzliche Sicherungsschritte notwendig.

Schritt 19: Die ODBC Konfiguration

Damit man über den Webserver auf die SAP-DB zugreifen kann, muss nun noch im Heimatverzeichniss des Webserver-"Users" die Datei .odbc.ini angelegt werden. Sollten Sie im vorigen Schritt den Parameter "User" in der httpd.conf auf "sapdb" umgestellt haben, muss nun die Datei /home/sapdb/.odbc.ini erzeugt werden. Fügen Sie dann folgende Zeilen in die Datei ein:
[saptest]

ServerDB = TST

ServerNode = localhost

Driver = /opt/sapdb/interfaces/odbc/lib/libsqlod.so

Description = Die SAP-DB Testdatenbank

Schritt 20: Der Test

Starten Sie zunächst den Webserver mit dem Befehl
/etc/init.d/apachectl start
Sollte es dabei zu keinen Problemen kommen, können Sie nun Ihr SAP System testen. Legen Sie dazu die Datei /usr/local/apache/htdocs/test.php mit folgendem Inhalt an:
<?

echo "<b>Die Verbindung zur Datenbank wird aufgebaut.</b>";

$conn = odbc_connect("saptest","dba","dba") or die ("Verbindung zur Datenbank konnte nicht hergestellt werden");

echo "<br>Verbindung wurde hergestellt<br><br>";

echo "Lese Benutzertabelle aus Datenbank aus...<br>";

$result = odbc_do($conn,"select * from users");

odbc_result_all($result);

echo "<br>Lese Testtabelle aus...<br>";

$result = odbc_do($conn,"select * from customer");

odbc_result_all($result);

odbc_close($conn);

echo "<br><b>Verbindung abgebaut</b>";

?>

Rufen Sie nun die Seite "test.php" in Ihrem Browser auf:
http://<Linuxrechnername>/test.php
Wenn Sie nun die unter Schritt 8 angelegten Daten sehen, haben Sie es geschafft.

Ende und Danksagung

Sie haben es nun also geschafft! Herzlichen Glückwunsch! Freuen Sie sich über einen kompakten Webserver, eine flexible Programmiersprache und eine professionelle Datenbank. Zu meiner Freude durfte ich feststellen, dass die SAP-DB ab SuSE 7.2 standardmässig in die beliebte deutsche Linux-Distribution eingegliedert wurde. Dies zeigt sicherlich, dass Linux und SAP auch in der Zukunft eine vielversprechende Kombination darstellt.
Zu guter Letzt möchte ich an dieser Stelle noch Jörg Baach und Andreas Wildner danken, ohne deren Webseiten diese Zusammenstellung nicht möglich gewesen wäre. Last but not least sei auch noch Oliver Rahn für seinen Rund-um-die-Uhr-Linux-Support gedankt, mit dem er mich mehr als einmal aus einer vermeindlichen Konfigurations-Sackgasse geholt hat. Danke!
Für Fragen, Anregungen und Kommentare zu diesem Text stehe ich natürlich gerne zur Verfügung.
Zu erreichen bin ich unter
andreas.ditze@gmx.de
Giessen, den 25.06.2001
Letztes Update am 29.8.2001

Zurück zur Startseite

Diese Seite wurde seit dem 25.6.2001 Mal aufgerufen.