PHP 5.1.1 findet Apache nicht?

[croc]

Mein Apache liegt in /home/apachesmall/
Der Apachesourcecode liegt in /home/apachesmall/httpd-2.2.0/
Der PHP Sourcecode liegt in /home/apachesmall/php-5.1.1/

die configurephp enthält folgende Zeile:
./configure --without-pear --enable-shared --prefix=/home/apachesmall/php --with-apxs2=/home/apachesmall/bin/apxs --with-apache=/home/apachesmall --enable-embed=shared

Code: Select all

vs185244:/home/apachesmall/php-5.1.1 # ./configurephp
loading cache ./config.cache
checking for Cygwin environment... no
checking for mingw32 environment... no
checking for egrep... grep -E
checking for a sed that does not truncate output... //bin/sed
checking host system type... i686-pc-linux-gnu
checking target system type... i686-pc-linux-gnu
checking for gcc... gcc
checking whether the C compiler (gcc  ) works... yes
checking whether the C compiler (gcc  ) is a cross-compiler... no
checking whether we are using GNU C... yes
checking whether gcc accepts -g... yes
checking whether gcc and cc understand -c and -o together... yes
checking how to run the C preprocessor... gcc -E
checking for AIX... no
checking whether ln -s works... yes
checking if compiler supports -R... no
checking if compiler supports -Wl,-rpath,... yes
checking for re2c... no
configure: warning: You will need re2c 0.98 or later if you want to regenerate PHP parsers.
checking for gawk... gawk
checking for bison... no
checking for byacc... no
checking for bison version... invalid
configure: warning: bison versions supported for regeneration of the Zend/PHP parsers: 1.28 1.35 1.75 1.875 2.0 2.1 (found: none).
checking for flex... flex
checking for yywrap in -lfl... yes
checking lex output file root... lex.yy
checking whether yytext is a pointer... yes
checking for working const... yes
checking for flex version... 2.5.4 (ok)
checking whether to force non-PIC code in shared modules... yes
checking for pthreads_cflags... -pthread
checking for pthreads_lib...

Configuring SAPI modules
checking for AOLserver support... no
checking for Apache 1.x module support via DSO through APXS... no
checking for Apache 1.x module support... no
configure: error: Invalid Apache directory - unable to find httpd.h under /home/apachesmall
vs185244:/home/apachesmall/php-5.1.1 # whereis httpd.h
httpd:

Warum findet das configureprogramm von php nicht das apacheverzeichnis?

[blnsnoopy26]

wenn er die httpd.h ned finden kann, fehlt das entsprechende devel paket. Nachinstallieren dann wirds auch gefunden.

[Joe User]

--with-apxs2=/home/apachesmall/bin/apxs --with-apache=/home/apachesmall

Du musst Dich schon für eine Apacheversion entscheiden:
--apxs2 = Apache2
--with-apache = Apache1

[croc]

Also das Kompilieren von PHP und die Einbindung in Apache hat jetzt einwandfrei funktioniert.
Nun stehe ich allerdings vor einem neuen Problem.
Wenn ich eine php datei nun aufrufen will über den browser kommt eine leere seite. Ich hab auf "Quelltext anzeigen" geklickt und es erscheint dann der quelltext der php datei. Ihr Inhalt wird also nicht geparst.

In meiner httpd.conf hab ich folgendes hinzugefügt:
LoadModule php5_module php/lib/libphp5.so
AddType application/x-httpd-php .php
AddType application/x-httpd-php-source .phps

Damit ging es aber auch nicht, dann hab ich das noch in den vhost eingetragen und damit wirds auch nicht besser.

Wo könnte da der Fehler sein?

[Joe User]

AddHandler statt AddType verwenden:

Code: Select all

AddHandler application/x-httpd-php .php
AddHandler application/x-httpd-php-source .phps

Stimmt der Pfad zur libphp5.so? php.ini-recommended an Dein System angepasst und entsprechend abgelegt? phpinfo() funktioniert?

[croc]

Also das mit AddHandler löst mein Problem nicht, funktioniert immernoch nicht.

Auszug der error_log:
[Thu Jan 12 14:11:01 2006] [warn] module php5_module is already loaded, skipping
[Thu Jan 12 14:11:01 2006] [notice] Apache/2.2.0 (Unix) PHP/5.1.1 configured -- resuming normal operations

Die Pfade müssten auch stimmen!
kompilierter Apache:
/home/apachesmall
kompiliertes PHP:
/home/apachesmall/php
Pfad zur libphp5.so:
/home/apachesmall/php/lib
Pfad zur php.ini
/home/apachesmall/php/lib

Aktuelle Einträge der httpd.conf und des vhosts:
LoadModule php5_module php/lib/libphp5.so
AddHandler application/x-httpd-php .php
AddHandler application/x-httpd-php-source .phps

Meiner Meinung nach stimmt ja alles, aber es funktioniert trotzdem nicht. Die Fehlerbeschreibung ist die gleiche wie vorhin. PHP-Datei im Browser laden --> leere Seite mit dem Quelltext:
<?
$version = phpversion();
phpinfo()
?>

[Joe User]

Aktuelle Einträge der httpd.conf und des vhosts:
LoadModule php5_module php/lib/libphp5.so
AddHandler application/x-httpd-php .php
AddHandler application/x-httpd-php-source .phps

Die Directiven gehören nur in den allgemeinen Abschnitt der httpd.conf, nicht in den Abschnitt des vHosts.

PHP-Datei im Browser laden --> leere Seite mit dem Quelltext:
<?
$version = phpversion();
phpinfo()
?>

Versuche es mal mit <?php statt <? und gewöhne Dich gleich daran (Shortopen-Tags werden wahrscheinlich mit PHP6 abgeschafft).

[croc]

Jetzt funktioniert es. Die php-datei wird angezeigt und es werden auch alle informationen der funktion phpinfo() richtig angezeigt.

Eine Zeile kommt mir aber seltsam vor:
User/Group daemon(2)/2

In der Datei mit den vhosts, welche auch geladen sein müsste, steht folgendes:
NameVirtualHost *:80
<VirtualHost *:80>
ServerAdmin ****@****.de
DocumentRoot /home/apachesmall/htdocs
SuexecUserGroup www users
ScriptAlias htdocs /home/apachesmall/htdocs/
ServerName ******.de
ServerAlias ******.de
ErrorLog logs/******.de-error_log
CustomLog logs/******.de-access_log common
</VirtualHost>

Obwohl SuExec auch als modul geladen ist, wird die datei php_info.php nicht als benutzer www ausgeführt, wie es sein sollte, sondern als benutzer daemon.

Wo könnte da der Fehler sein?

[Joe User]

Du hast PHP als Apache-Modul installiert, folglich werden PHP-Scripte mit dem User und den Rechten des Apache ausgeführt. Wenn Du Apache als User daemon startest, werden PHP-Scripte ebenfalls als User daemon ausgeführt. SuExec kommt gar nicht erst zum Zug, da SuExec nur für CGI-Scripte zuständig ist.

[croc]

und welche möglichkeiten gibt es um das php-script php_info.php als benutzer www und der gruppe users ausführen zu können?

[Joe User]

PHP als (Fast)CGI kompilieren/einbinden und auf mod_php verzichten.

[croc]

Hm, schonmal gut zu wissen. (danke für die Information)
aber wie geht das eigentlich? (Mini-Howto ?)
Ich hab das noch nie als CGI gemacht.

[Roger Wilco]

aber wie geht das eigentlich? (Mini-Howto ?)
Ich hab das noch nie als CGI gemacht.

http://www.debianhowto.de/de:howtos:sar ... 2_php-fcgi

Eine weitere Alternative wäre SuPHP. Danach darfst du aber noch selbst suchen. ;)

[intpoint]

PHP als (Fast)CGI kompilieren/einbinden und auf mod_php verzichten.

Hallo

Mein erstes Posting in diesem Board!

Vom kompilieren als (FAST) CGI kann ich nur abraten! Die vermeintlichen Vorteile sind mir zwar bekannt, beziehen diese sich jedoch nicht auf die hier gewünschte PHP Version 5.1.1. Es gibt in der gewünschten Version eine Option "--with-zend-vm=GOTO" (http://www.sebastian-bergmann.de/blog/a ... mance.html) was der Performance von (FAST) CGI mehr als gerecht werden sollte.

Lg. INTpoint

[Roger Wilco]

Die vermeintlichen Vorteile sind mir zwar bekannt, beziehen diese sich jedoch nicht auf die hier gewünschte PHP Version 5.1.1.

Doch, die beziehen sich auch noch auf PHP 5.1.x. Bei FastCGI geht es um die Persistenz des Interpreters, so dass nicht der ganze Schmodder bei jedem Aufruf neu geladen werden muß, wie bei der Einbindung via CGI oder SuPHP.

Es gibt in der gewünschten Version eine Option "--with-zend-vm=GOTO" (http://www.sebastian-bergmann.de/blog/a ... mance.html) was der Performance von (FAST) CGI mehr als gerecht werden sollte.

Erklärst du bitte noch den Zusammenhang? Ja, es gibt die Möglichkeit die Zend VM zu beeinflussen. Aber was hat das mit FastCGI zu tun?

[intpoint]

Erklärst du bitte noch den Zusammenhang? Ja, es gibt die Möglichkeit die Zend VM zu beeinflussen. Aber was hat das mit FastCGI zu tun?

Vielleicht verstehe ich FAST-CGI überhaubt nicht. Last Update evtl.: http://www.fastcgi.com/ year 2004; Zend Engine 1 & Apache 2.0.43.

Also stelle ich Dir die Frage, was macht FAST-CGI in VERBINDUNG mit der PDO PGSQL; FIREBIRD interessant? Ich sehe zumindest derzeit nichts.

Lg. INTpoint

[Roger Wilco]

Vielleicht verstehe ich FAST-CGI überhaubt nicht.

Ja, den Eindruck habe ich auch. ;)
FastCGI ist ein Protokoll wie CGI. Das scheinst du nicht verstanden zu haben.

Last Update evtl.: http://www.fastcgi.com/ year 2004; Zend Engine 1 & Apache 2.0.43.

Erstens läuft mod_fastcgi auch mit neueren Apacheversionen (z. B. 2.0.55).
Zweitens ist es FastCGI doch egal, welcher Interpreter dadurch eingebunden wird (also z. B. auch PHP 5.1.2 oder trunk). Und drittens gibt es durchaus auch geglückte FastCGI-Implementationen (z. B. mod_fcgid für den Apache oder mod_fastcgi von lighttpd).

Also stelle ich Dir die Frage, was macht FAST-CGI in VERBINDUNG mit der PDO PGSQL; FIREBIRD interessant? Ich sehe zumindest derzeit nichts.

Speicherpersistenz des Interpreters. Der Webserver muß den Interpreter nicht für jeden Request neu forken und es wird weniger Speicher verbraucht, als wenn der Interpreter als Modul im Webserver läuft. Desweiteren muß der Interpreter nichtmal auf dem gleichen Rechner laufen, sondern kann über das Netzwerk auf einem anderen Server angesprochen werden. Das ist schön für größere Setups. Außerdem werden dadurch im Fall des Apache httpd andere MPM als prefork nutzbar (Stichwort Threadsicherheit von PHP).

[Joe User]

Vielleicht verstehe ich FAST-CGI überhaubt nicht.

Richtig, ebensowenig wie den Rest dieses Threads. Roger hat Dir ja schon (auch in anderen Threads) das Wichtigste zum Thema erläutert, den Rest findest Du per Google...

[kennethsoona]

Suse 9.1 Minimalkonfiguration (Alturo)

ich hab apache2.2 installiert

# gzip -d httpd-2.2.0.tar.gz
# tar xvf httpd-2.2.0.tar.gz

# ./configure --prefix=/usr/local/apache2
# make
# make install

Apache startet, ist erreichbar.


dann PHP5

# gzip -d php-5.1.2.tar.gz
# tar xvf php-5.1.2.tar

# ./configure
--with-ldap=yes
--with-gd=yes
--with-zlib=yes
--with-config-file-path=/etc
--with-apxs2=/usr/local/apache2/bin/apxs
--enable-track-vars
--enable-thread-safety
--disable-cgi

leider finde ich keine libphp5.so bzw. irgendeine *php*so Datei! Natürlich kann ich somit auch nicht über die httpd.conf dieses Modul laden weil es nicht gefunden wird.

Was mache ich falsch? Sollte ich Apache 2.0.x verwenden?

Bitte keine Ratschläge, die Pakete zu installieren. Ich möchte hier nur Tipps zur Kompilierung bzw. Problemlösungen die meine Kompilierungen betreffen.

cgi kommt nicht in Frage...

[oxygen]

Also wenn man so gut wie nichts von der Materie versteht (Die ./configure Zeile deines PHPs lässt das vermuten), sollte man nun wirklich nicht bleeding edge Versionen ala Apache 2.2 oder PHP 5.1 auf einem produktiven System installieren. (Wenn man was davon versteht, tut man das sowieso nicht) Wenn dir die Versionen der Distribution zu alt sind (was ich mir bei SuSE 9.1 schon vorstellen kann), benutz passende Pakete. von SuSE werden z.b. aktuelle PHP und Apache Versionen auch für ältere Versionen zur Verfügung gestellt.
Wenn dir das nicht reicht, installier dir eine aktuellere Distribution. z.B. Debian Sarge oder Gentoo.

[kennethsoona]

Die Zeilen sind aus der Dokumentation zu Apache und PHP.

Warum sagst Du, ich hätte KEINE Ahnung?

Sag mir lieber was nicht stimmt. Ich hab beruflich damit wenig zu tun, meine Stärken liegen wo anders. Das soll aber meiner Meinung nach nicht heißen, dass ich mir nich selbst beibringen darf wie man das kompiliert wird oder?

Ich finde das mittlerweile ziehmlichen Mist. Wenn irgendwann jemand danach googlelt findet er Deine tolle Antwort und denkt sich wahrscheinlich das gleiche wie ich.

Die Foren sind mittlerweile alle zugemüllt von Antworten, die keine Lösung beschreiben. Das erschwert die ganze Situtation nur unnötig.

Das ist übrigens die Meinung von vielen...

[oxygen]

Die Zeilen sind aus der Dokumentation zu Apache und PHP.

Warum sagst Du, ich hätte KEINE Ahnung?

hab ich das? Mir war nur klar, dass diese Zeilen nicht wirklich zu einer Rootserver Konfiguration passen, egal wo sie nun herstammen. Zumindest habe ich noch keine Rootserver gesehen, wo --with-ldap gebraucht wird. Da könnte im übrigen auch der Fehler liegen. Allerdings lässt sich das schwer sagen, ohne die Ausgaben von ./configure und make.

Sag mir lieber was nicht stimmt. Ich hab beruflich damit wenig zu tun, meine Stärken liegen wo anders. Das soll aber meiner Meinung nach nicht heißen, dass ich mir nich selbst beibringen darf wie man das kompiliert wird oder?

Das darfst du freilich. Aber ich halte es für unklug, dass auf einem Rootserver zu tun, den du möglicherweise beruflich brauchst. Wenn dann etwas nicht funktioniert wie es soll, ist das Geheule meist groß.
Wenn man lernen und probieren will, macht man das am besten im stillen Kämmerlein zu Haus z.B. an einem alten Rechner.

Ich finde das mittlerweile ziehmlichen Mist. Wenn irgendwann jemand danach googlelt findet er Deine tolle Antwort und denkt sich wahrscheinlich das gleiche wie ich.

Die Foren sind mittlerweile alle zugemüllt von Antworten, die keine Lösung beschreiben. Das erschwert die ganze Situtation nur unnötig.

Die beste Lösung ist und bleibt Hilfe zur Selbsthilfe.

Das ist übrigens die Meinung von vielen...

s.o.

[kennethsoona]

Also wenn man so gut wie nichts von der Materie versteht (Die ./configure Zeile deines PHPs lässt das vermuten),

Veranlasste mich das zu denken. Entschuldige, wenn ich es falsch verstanden habe.

Zumindest habe ich noch keine Rootserver gesehen, wo --with-ldap gebraucht wird. Da könnte im übrigen auch der Fehler liegen.

O'Reilly - Wegweiser zur Installation & Konfiguration. Da wirds so aufgerufen. Ohne ist es aber genauso.

Ich dachte nur, dass es evtl. ein typischer Fehler sei, wenn das Modul fehlt. Ich leite jetzt mal die Ausgaben von ./configure und make in eine datei und sehe sie mir durch...

Der Server gehört mir persönlich und wird nie beruflich genutzt. Ich nutze das lediglich zur beruflichen weiterbildung. Hauptsächlich aber auch um neue Möglichkeiten eines LAMP-Systems zu testen. Man hört ja so viel neues und möchte das einfach mal testen. Spricht ja nichts dagenen. Wenns nicht passt oder unbrauchbar wird kann ich jederzeit wieder die Minimalkonfigutaion setzen. Das ist also ein reiner Testserver.

[sledge0303]

PHP als (Fast)CGI kompilieren/einbinden und auf mod_php verzichten.

Er hat Apache 2.2.0 installiert und da wird FastCGI noch nicht unterstützt.

[Joe User]

Daher steht das Fast auch in Klammern...