search
subnavi
Was ist PHP?
PHP Forum
PHP Wiki
PHP Handbuch
PHP FAQ
PHP News
PHP News melden
PHP Downloads
PHP Editoren
PHP Bücher
PHP Zeitschriften
PHP Webspace
PHP Jobbörse
Werbung

Installation und Inbetriebnahme

Frage: Wie kompiliere ich ein aktuelles PHP auf Linux mit Apache Server?

Antwort von Kristian Köhntopp:

Eine gute Hilfe findet sich bei Apache 2 and PHP (mod_php) on Linux .

Frage: Ich habe Probleme PHP selbst zu kompilieren.

Antwort von Kristian Köhntopp:

config.cache nicht gelöscht.

Beim Selbstübersetzen von PHP werden gelegentlich neu installierte Bibliotheken nicht oder in der falschen Version gefunden. In diesem Fall ist meistens eine veraltete Datei config.cache aus einem früheren Lauf von configure schuld. Diese Datei muss gelöscht werden, danach werden die neuen Bibliotheken korrekt gefunden.

Frage: Wie installiere ich CGI-PHP auf einem Apache-Server?

Antwort von Kristian Köhntopp:

Schritt 1: Man definiert ein Verzeichnis als CGI Verzeichnis: 

<Directory /home/www/servers/phplib.shonline.de/cgi/>
Options ExecCGI
AllowOverride None
</Directory>

Hier wird das Verzeichnis /home/www/.../cgi als Verzeichnis zur Ausführung von CGI-Dateien gekennzeichnet, indem für das Verzeichnis das ExecCGI Attribut gesetzt wird.

Schritt 2: Man definiert für dieses Verzeichnis eine URL 

ScriptAlias  /cgi/      /home/www/servers/phplib.shonline.de/cgi/

Die URL /cgi/ wird jetzt auf dieses Verzeichnis /home/www/.../cgi/ abgebildet.

Man kann jetzt in diesem Verzeichnis eine ausführbare Datei (etwa ein Shellscript) ablegen, die den folgenden Text ausgibt, wenn man sie startet. 

Content-Type: text/plain

Hallo, Welt.

Wenn man diese Datei unter der URL http://meinserver.de/cgi/name_des-scripts aufruft, muss man den Text "Hallo, Welt." angezeigt bekommen. Gelingt dies nicht, sollte man durch das Error Log toben und nachsehen, was dort schiefgeht.

Schritt 3: Man installiert den PHP-Interpreter im CGI-Verzeichnis und prüft, ob man ihn als CGI-Programm aufrufen kann. Dazu ist der Interpreter nach /home/www/.../cgi zu kopieren und dann unter der URL http://.../cgi/php oder http://.../cgi/php.exe oder wie immer der Interpreter heißt aufzurufen.

Dabei muss die folgende Fehlermeldung kommen: 

Security Alert! PHP CGI cannot be accessed directly.

This PHP CGI binary was compiled with force-cgi-redirect
enabled. This means that a page will only be served up if the
REDIRECT_STATUS CGI variable is set. This variable is set, for
example, by Apache's Action directive redirect.

Kommt die Meldung nicht, ist das PHP-Binary unsicher und sollte durch ein korrekt kompiliertes Binary ersetzt werden.

Schritt 4: Man definiert eine Scriptaktion, die das o.a. Binary startet und definiert eine Endung, die durch diese Aktion abgehandelt wird:

    • Action php-script /cgi/php

      teilt dem Apache mit, dass der interne MIME-Typ php-script durch die URL /cgi/php (oder wie immer die URL zum Aufruf des PHP-Interpreters aus Schritt 3 heißt) abgehandelt wird. Der MIME-Typ php-script ist illegal und das ist gut so, denn er wird nur innerhalb von Apache verwendet (er darf nur innerhalb von Apache verwendet werden!).

    • AddHandler php-script .php

      teilt Apache weiterhin mit, dass die Endung .php durch den MIME-Handler für den MIME-Type php-script abgehandelt wird.

Frage: Wie installiere ich PHP auf Windows?

Antwort von Martin Jansen:

Bei der Installation von PHP unter Windows hat man ebenso wie unter Unix/Linux die Möglichkeit, PHP als CGI-Version oder als Modul für den Apache Webserver zu installieren. Die Vor- und Nachteile der verschiedenen Versionen werden im Artikel php-cgi-vs-modul erläutert.

Sowohl die CGI- als auch die Modul-Version sind auf der offiziellen Downloadseite erhältlich.

Mit der Modul-Version ist es zur Zeit jedoch nicht möglich, die GD-Library bzw. die Sablotron-Library zu nutzen, da diese nicht threadsafe sind.

Die offizielle Installationsanleitung für die CGI-Version in englischer Sprache befindet sich auf dem offiziellen PHP-Server .

In deutscher Sprache findet man zur selben Frage eine umfangreiche WAMP-Anleitung auf infos24. Viele weitere Tutorials zu diesem Thema findet Google.

Zur Installation der Modul-Version schrieb Björn Höhrmann am 20.07.2000 in de.comp.lang.php folgendes: 

Zur Installation:

WinNT4:       E:\Winnt\
Apache:       E:\winapp\apache\
PHP4 Module:  E:\winapp\apache\php4module\

E:\winapp\apache\conf\httpd.conf:
 + LoadModule php4_module php4module/php4apache.dll
 + AddType application/x-httpd-php .php

E:\winapp\apache\php4module\php.ini:
 > Kopiert nach E:\Winnt\

[...]

E:\winapp\apache>set path=%path%;e:\winapp\apache\php4module\
E:\winapp\apache>apache -k start
Apache/1.3.11 (WunLix) PHP/4.0.2-dev running...

[...]

Darüber hinaus gibt es mehrere Pakete, die eine komplette Serverumgebung inkl. PHP und MySQL auf einem Windows-Rechner installieren.

    • AppServ Open Project

    • phpdev (nicht ganz aktuell)

    • EasyPHP (relativ aktuell)

    • Das derzeit aktuellste Paket ist XAMPP für Windows , das auch mod_perl, mod_ssl und einiges mehr enthält. Es ist auch eine Version mit PHP 5 erhältlich, wenn man seine Programme bereits mit PHP 5 testen will.

Frage: Linux: Meine shared libraries werden nicht gefunden.

Antwort von Kristian Köhntopp:

Übersetzt man PHP selbst und bindet dabei auch selbst installierte Module und Bibliotheken mit ein, kann es vorkommen, dass das Modul vom Apache nicht geladen wird, weil diese externen Bibliotheken nicht gefunden werden. Im folgenden wird erläutert, was es mit diesen Bibliotheken auf sich hat. 

kris@valiant:~ > ldd /bin/ls
        libc.so.6 => /lib/libc.so.6 (0x4001f000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

Damit man das Kommando ls ausführen kann, müssen die Dateien ld-linux.so.2 und libc.so.6 vorhanden sein. Diese Dateien sucht mein System in den in /etc/ld.so.conf genannten Verzeichnissen. Damit dies schneller geht, legt das Kommando ldconfig einen Cache der Bibliotheken in diesen Verzeichnissen an. Mit diesen Caches wird ein Durchsuchen aller Verzeichnisse in /etc/ld.so.conf beim Start von Programmen vermieden. Stattdessen stehen in /etc/ld.so.cache Paare von Bibliotheksname und Pfadname, die sofort zugreifbar sind.

Ein laufendes ls hat also /lib/ld-linux.so.2 und /lib/libc.so.6 geladen. Das kann man auch nachsehen: 

kris@valiant:~ > sleep 3600 &
[1] 27091
kris@valiant:~ > cat /proc/27091/maps
08048000-0804a000 r-xp 00000000 08:15 63535      /bin/sleep
0804a000-0804b000 rw-p 00001000 08:15 63535      /bin/sleep
40000000-40013000 r-xp 00000000 08:15 71682      /lib/ld-2.1.3.so
40013000-40014000 rw-p 00012000 08:15 71682      /lib/ld-2.1.3.so
4001e000-4001f000 rw-p 00000000 00:00 0
4001f000-400f9000 r-xp 00000000 08:15 71690      /lib/libc.so.6
400f9000-400fe000 rw-p 000d9000 08:15 71690      /lib/libc.so.6
400fe000-40101000 rw-p 00000000 00:00 0
bfffe000-c0000000 rwxp fffff000 00:00 0
kris@valiant:~ > ldd `which sleep`
        libc.so.6 => /lib/libc.so.6 (0x4001f000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
kris@valiant:~ > ls -l /lib/ld-linux.so.2
lrwxrwxrwx   1 root     root       11 Apr 11 18:16 /lib/ld-linux.so.2
                                                   -> ld-2.1.3.so
kris@valiant:~ > kill %1
kris@valiant:~ >
[1]+  Terminated              sleep 3600

Tatsächlich gibt die Ausgabe der Memory-Map für den Prozess 27091 (sleep) an, dass /lib/ld-2.1.3.so aka /lib/ld-linux.so.2 und /lib/libc.so.6 geladen sind - man kann deutlich die schreibgeschützten Code-Segmente ( r-xp ) und die überschreibbaren, nicht ausführbaren Datensegmente ( rw-p ) dieser Bibliotheken erkennen.

Will ich nun mein PHP4 starten, dann wird 

kris@valiant:~ > ldd /usr/lib/apache/libphp4.so
        libgdbm.so.2 => /usr/lib/libgdbm.so.2 (0x4015b000)
        libpam.so.0 => /lib/libpam.so.0 (0x40162000)
        librecode.so.0 => /usr/lib/librecode.so.0 (0x4016a000)
        libdl.so.2 => /lib/libdl.so.2 (0x401e6000)
        libsnmp.so => /usr/lib/libsnmp.so (0x401ea000)
        libpdf.so.0 => /usr/lib/libpdf.so.0 (0x40225000)
        libtiff.so.3 => /usr/lib/libtiff.so.3 (0x4024e000)
        libldap.so.1 => /usr/lib/libldap.so.1 (0x40291000)
        libttf.so.2 => /usr/lib/libttf.so.2 (0x402a6000)
        libjpeg.so.62 => /usr/lib/libjpeg.so.62 (0x402cf000)
        libpng.so.2 => /usr/lib/libpng.so.2 (0x402ee000)
        libz.so.1 => /usr/lib/libz.so.1 (0x4030b000)
        libresolv.so.2 => /lib/libresolv.so.2 (0x4031b000)
        libm.so.6 => /lib/libm.so.6 (0x4032a000)
        libcrypt.so.1 => /lib/libcrypt.so.1 (0x40347000)
        libnsl.so.1 => /lib/libnsl.so.1 (0x40374000)
        liblber.so.1 => /usr/lib/liblber.so.1 (0x4038b000)
        libc.so.6 => /lib/libc.so.6 (0x40390000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000)

geladen, d.h. ein 

kris@valiant:~ > grep LoadModule /etc/httpd/httpd.conf | grep php
LoadModule php4_module /usr/lib/apache/libphp4.so

in der Apache-Konfiguration kann nur dann gelingen, wenn all die o.a. Bibliotheken vorhanden sind. Sind sie es nicht, schlägt das Laden des Moduls fehl: 

kris@valiant:~ > su -
Password:
valiant:~ # mv /usr/lib/libpng.so.2 /usr/lib/libpng.so.2.offline
valiant:~ # ldd /usr/lib/apache/libphp4.so
        libgdbm.so.2 => /usr/lib/libgdbm.so.2 (0x4015b000)
        libpam.so.0 => /lib/libpam.so.0 (0x40162000)
        librecode.so.0 => /usr/lib/librecode.so.0 (0x4016a000)
        libdl.so.2 => /lib/libdl.so.2 (0x401e6000)
        libsnmp.so => /usr/lib/libsnmp.so (0x401ea000)
        libpdf.so.0 => /usr/lib/libpdf.so.0 (0x40225000)
        libtiff.so.3 => /usr/lib/libtiff.so.3 (0x4024e000)
        libldap.so.1 => /usr/lib/libldap.so.1 (0x40291000)
        libttf.so.2 => /usr/lib/libttf.so.2 (0x402a6000)
        libjpeg.so.62 => /usr/lib/libjpeg.so.62 (0x402cf000)

<<<     libpng.so.2 => not found >>>

        libz.so.1 => /usr/lib/libz.so.1 (0x402ee000)
        libresolv.so.2 => /lib/libresolv.so.2 (0x402fe000)
        libm.so.6 => /lib/libm.so.6 (0x4030d000)
        libcrypt.so.1 => /lib/libcrypt.so.1 (0x4032a000)
        libnsl.so.1 => /lib/libnsl.so.1 (0x40357000)
        liblber.so.1 => /usr/lib/liblber.so.1 (0x4036e000)
        libc.so.6 => /lib/libc.so.6 (0x40373000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000)
valiant:~ # mv /usr/lib/libpng.so.2.offline /usr/lib/libpng.so.2
valiant:~ # logout
kris@valiant:~ >

Note: Do not try this at home, kids! Wenn man das mit der falschen Bibliothek macht (ld-linux und libc sind gute Kandidaten), kann man schon mal die Rettungs-CD rauskramen und die Termine am Nachmittag absagen.

Wenn die fehlende Bibliothek also nicht installiert ist, kann es nicht gehen. Wenn die fehlende Bibliothek nicht gefunden wird, dann ist /etc/ld.so.conf unvollständig und muss ergänzt werden. Wenn die fehlende Bibliothek nicht gefunden wird, aber installiert ist und in einem in /etc/ld.so.conf genannten Pfad installiert ist, dann muss ldconfig neu aufgerufen werden, damit /etc/ld.so.cache neu gebaut wird.

Frage: SuSE Linux: Beim compilieren wird lex nicht gefunden

Antwort von Matthias P. Wuerfl:

Um PHP auf den aktuellen SuSE-Distributionen zu installieren braucht man flex. Wenn flex nicht installiert ist, dann bricht ./configure mit Meldungen ab wie: 

checking for flex... no
checking for lex... no
./configure: flex: command not found
checking for flex... lex
checking for yywrap in -ll... no
checking lex output file root... ./configure: lex: command not found
configure: error: cannot find output from lex; giving up

Flex findet man in der Serie d auf den SuSE-CDs und auch auf dem SuSE ftp-Server. Es kann einfach per YaST installiert werden.