php binary verlinken & suphp ersatz.

[blnsnoopy26]

Hi,

Und zwar habe ich ein Projekt, das es erfordert, das php als CGI laufen muss. Weil die User wohl mit der Kompelierung von Suphp nicht richtig zurecht kommen, wollte ich mal fragen, wenn man jetzt php als CGI starten möchte und unter dem selben owner dem das Verzeichnis gehört einfach das php Binary per symlink in das entsprechende Verzeichnis linken tut, wo die php dateien sind?

Zum Einsatz kommt da ein Rooti von 1&1 mit Apache2 und SusE 9.0

Vorstellen tu ich mir das so:

Code: Select all

ln -s /usr/bin/php /home/htdocs/web1/html
chmod 755 /home/htdocs/web1/html/php
chown web1:web1 /home/htdocs/web1/html/php

damit währe das Binary nach html verlinkt und rechte 755 und hat user und Gruppe web1:web1. reicht das, wenn man dies so macht, oder muss ich den php scripten noch folgendes eintragen:

Code: Select all

#!/home/htdocs/web1/html/php
<?php
[...]
phpcode
?>

Währe da sehr dankbar, wenn mir da jemand diesbezüglich helfen kann.
Hab zwar hier im Forum schon danach gesucht, nur das passende war für mich jetzt nicht mit dabei.

[Roger Wilco]

Guck mal da.

Warum willst du eigentlich einen Symlink des PHP-Binaries in das Home-Directory des Benutzers machen?

[blnsnoopy26]

Hi,

Ist ja alles für Debian beschrieben wie so vieles hier im Forum.
PHP ist bei mir schon als CGI installiert und Suexec ist auch installiert.

Warum willst du eigentlich einen Symlink des PHP-Binaries in das Home-Directory des Benutzers machen?

Weil ich hier im Forum viel gelesen habe das man das binary von php in das Verzeichnis des Users packen soll. Aber bei vielen Kunden ist das Spiecherplatz verschwendung, daher die Symlink Idee.

So zum Thema zurück...

Meine Vhost mit suphp sieht im moment so aus:

Code: Select all

<VirtualHost 82.165.xxx.xxx:80>
  ServerName mydomain.de
  ServerAlias www.test.mydomain.de test.mydomain.de
  DocumentRoot /home/htdocs/web1/html/test/
  SuexecUserGroup web1 ftponly
  ScriptAlias /cgi-bin/ /home/htdocs/web1/html/cgi-bin/
  php_admin_value upload_tmp_dir /home/htdocs/web1/phptmp/
  suPHP_Engine on
  php_admin_flag engine on
  AddType application/x-httpd-php .php .php3 .php4 .html
  AddHandler x-httpd-php .php .php3 .php4 .html
  php_admin_flag safe_mode Off
  #php_admin_flag register_globals on
</VirtualHost>

So wenn ich die doku richtig verstanden habe, müsste ich es bei mir quasi so anwenden, weil PHP ist ja schon als CGI Kompeliert.

Code: Select all

<VirtualHost 82.165.xxx.xxx:80>
  ServerName mydomain.de
  ServerAlias www.test.mydomain.de test.mydomain.de
  DocumentRoot /home/htdocs/web1/html/test/
  SuexecUserGroup web1 ftponly
  ScriptAlias /cgi-bin/ /home/htdocs/web1/html/cgi-bin/
  php_admin_value upload_tmp_dir /home/htdocs/web1/phptmp/
  AddHandler cgi-script .php .cgi .sh .pl

<Directory /home/htdocs/web1/html/test/>
        Options +ExecCGI
        Order Deny,Allow
        Allow from all
    </Directory>
</VirtualHost>

[Joe User]

php_* (httpd.conf) können nur mit mod_php verwendet werden...

[Roger Wilco]

Ist ja alles für Debian beschrieben wie so vieles hier im Forum.

Komisch, bei mir ist die Apache-Konfiguration unter SuSE, Debian und Gentoo immer gleich gewesen. :roll:

Weil ich hier im Forum viel gelesen habe das man das binary von php in das Verzeichnis des Users packen soll. Aber bei vielen Kunden ist das Spiecherplatz verschwendung, daher die Symlink Idee.

Da wird dir SuExec dazwischenfunken.
Schau dir auch mal http://www.bwurst.org/archives/45-PHP-m ... entoo.html an (ich weiß, ist nicht SuSE, aber siehe Antwort oben...).

[alexander newald]

Schöner ist PHP mit suexec als CGI und binfmt_misc laufen zu lassen.

Apache normal mit suexec installieren, normalen VHost erstellen. Dann alle PHP Dateien normal uploaden/schreiben oder wie auch immer die normal in das Homeverzeichnis des VHost kommen.

In der httpd.conf muss

Code: Select all

AddHandler                 cgi-script .cgi .php .php3 .php4

und für den VHost ein

Code: Select all

Options +ExecCGI

stehen.

Jetzt kommts: Alle PHP Dateien ausführbar machen

z.B. chmod +x phpinfo.php

Damit die Datei beim Aufrufen automatisch ausgeführt wird, muss noch

Code: Select all

cd /proc/sys/fs/binfmt_misc
echo ':PHP:E::php::/usr/bin/php:' > register
echo ':PHP3:E::php3::/usr/bin/php:' > register
echo ':PHP4:E::php4::/usr/bin/php:' > register

einmal beim Systemstart aufgerufen werden.

Hat den Vorteil, dass man für die PHP Dateien kein

#!/usr/bin/php

am Anfang einfügen muss, und alle PHP Dateien trotzdem normal funktionieren.

[Roger Wilco]

Hat den Vorteil, dass man für die PHP Dateien kein

#!/usr/bin/php

am Anfang einfügen muss, und alle PHP Dateien trotzdem normal funktionieren.

Das erreicht man aber im Ã?brigen auch über die Direktiven

Code: Select all

AddType application/cgi-php php
Action application/cgi-php /cgi-wrapper/php

[alexander newald]

Es wird aber ein Wrapper benötigt, also ein Task mehr pro Aufruf einer PHP Datei gestartet.

[blnsnoopy26]

Hi,

Mal eine zwischenfrage. Ich seh grad das bei mir garkein suexec vorhanden ist. Kann man es einzeln nachinstallieren, oder müsste man da Apache selber kompelieren um es zu bekommen?

Weil hab Apache immer als RPM Installiert.
Weil kann es ja selbst garnicht testen :?


edit:

doch ist vorhanden :D
bei Apache2 heisst es ja suexec2 *lol*

[blnsnoopy26]

Hi,

Was ist denn da jetzt die einfachste Methode :?:
Es wurden nun viele Möglichkeiten vorgestellt, aber es währe schön, wenn mir einer von den vielen Möglichkeiten die einfachste aufzeigt. Ist ja nicht nur für mich sondern es kommt später auch in meine Anleitung mit rein und da sollte es dann so einfach wie möglich sein - wenn es geht :roll:

[Joe User]

Da unabhängig vom Kernel: http://www.rootforum.org/forum/viewtopi ... 240#227240

[Joe User]

Schöner ist PHP mit suexec als CGI und binfmt_misc laufen zu lassen.

Und wenn mir das entsprechende Kernel-Modul fehlt?

[blnsnoopy26]

Hi,

So habe mir nochmal alles genau durchgelesen und bin der meinung dies ist die Einfachste gut recht gut erklärte Anleitung.

Ich versuche das mal zu rekonstruieren und ihr könnt mir ja dann sagen ob ich da richtig liege oder nicht.

1.

Apache mit suexec Kompelieren, wenn nicht schon vorhanden

2.

PHP als CGI Kompelieren

3.

Binary kopieren -> in meinem Fall nach /home/htdocs/web1/html/cgi-bin

4.

Vhost erstellen:

Code: Select all

<VirtualHost 82.165.xxx.xxx:80> 
  ServerName mydomain.de 
  ServerAlias www.test.mydomain.de test.mydomain.de 
  DocumentRoot /home/htdocs/web1/html/
  SuexecUserGroup web1 ftponly 
  ScriptAlias /cgi-bin/ /home/htdocs/web1/html/cgi-bin/ 
  RemoveHandler .php
  AddType application/php php
  Action application/php /cgi-bin/php
</VirtualHost>

5.

Eine php z.b php.php Datei erstellen mit dem inhalt

Code: Select all

#!/bin/shexec /usr/bin/php "${PATH_TRANSLATED}"

Und diese auch dort hin kopieren, wo das php Binary liegt.

6.

Eine testdatei erstellen z.b phpinfo.php und schauen, ob es als CGI läuft.

Habe ich das so richtig verstanden oder habe ich da was falsch interpretiert :?:

[blnsnoopy26]

Hi,

Ich habe nun einmal das hier versucht:
http://www.bwurst.org/archives/45-PHP-m ... entoo.html

Hab das soweit auch verstanden und auch nachvollziehen können, nur funktioniert das leider nicht auf meinem Server.

Mein Vhost sieht nun so aus:

Code: Select all

<VirtualHost 82.165.xxx.xx:80>
  ServerName mydomain.de
  ServerAlias www.test.mydomain.de test.mydomain.de
  DocumentRoot /home/htdocs/web1/test/
  SuexecUserGroup web1 ftponly
  Options +ExecCGI
  php_admin_value upload_tmp_dir /home/htdocs/web1/phptmp/
  php_admin_flag engine on
  ScriptAlias /cgi-bin/ /home/htdocs/web1/test/cgi-bin/
  RemoveHandler .php
  AddType application/php php
  Action application/php /cgi-bin/php
</VirtualHost>

Desweiteren habe ich die index.php bei mir ausführbar gemacht mit chmod 755.

Rufe ich die datei auf, bekomme ich nur:

Die Anfrage kann nicht beantwortet werden, da im Server ein interner Fehler aufgetreten ist. Fehlermeldung:
Die Anfrage kann nicht beantwortet werden, da im Server ein interner Fehler aufgetreten ist. Der Server ist entweder überlastet oder ein Fehler in einem CGI-Skript ist aufgetreten.

die suexec.log sagt folgendes:

[2005-06-26 11:15:34]: uid: (636/web1) gid: (102/102) cmd: index.php
[2005-06-26 11:15:34]: command not in docroot (/home/htdocs/web1/test/cgi-bin/index.php)

Code: Select all

/usr/sbin/suexec2 -V
 -D AP_DOC_ROOT="/srv/www"
 -D AP_GID_MIN=96
 -D AP_HTTPD_USER="wwwrun"
 -D AP_LOG_EXEC="/var/log/apache2/suexec.log"
 -D AP_SAFE_PATH="/usr/local/bin:/usr/bin:/bin"
 -D AP_UID_MIN=96
 -D AP_USERDIR_SUFFIX="public_html"

Es wird zwar schon mit den richtigen Rechten ausgeführt, aber der docroot ist falsch, weil Apache ursprünglich für das verzeichnis /srv/www vorgesehn war, aber ich es nach /home verlegt habe sagt suexec mir, das es ein falsches docroot ist :( Kann man das irgendwie umgehen ohne mir ein eignen Apache zu kompelieren, weil hab alles immer per RPM installiert und auf komplett neu machen habe ich nicht so die lust.

So dann habe ich dort ein text gelesen:

Als erstes muss SuExec natürlich laufen. Das war bei uns schon vorher der Fall, trotzdem nochmal kurz zusammenfassend: SuExec braucht zur Kompilierzeit bereits die Angabe des Document-Root, also das Verzeichnis in dem alle Scripts drin sind. Gentoo stellt dieses auf /var/www ein, da wir /home haben wollen, mussten wir das ebuild patchen. jedenfalls steht da jetzt --with-suexec-docroot=/home.

was meinen die damit mit ebuild? Habe danach gegoogelt, aber da bekam ich keine richtigen antworten. Kann mir einer sagen, was ich da noch machen kann, ohne das ich Apache2 selber kompelieren muss?

[wgot]

Hallo,

Forumsuche nach suexec und docroot liefert massiv Vorschläge.

Gruß, Wolfgang

[Joe User]

ebuilds (portage->Gentoo) sind Vergleichbar mit den Specfiles für RPM...

[blnsnoopy26]

Hi,

Ich habe jetzt geschafft das suexec auf "/home/htdocs" schaut und es kommt nun auch kein docroot fehler mehr.

Code: Select all

 suexec2 -V
 -D AP_DOC_ROOT="/home/htdocs"
 -D AP_GID_MIN=96
 -D AP_HTTPD_USER="wwwrun"
 -D AP_LOG_EXEC="/var/log/apache2/suexec.log"
 -D AP_SAFE_PATH="/usr/local/bin:/usr/bin:/bin"
 -D AP_UID_MIN=96
 -D AP_USERDIR_SUFFIX="public_html"

suexec.log

Code: Select all

[2005-06-26 14:06:29]: uid: (636/web1) gid: (636/636) cmd: index.php

Sieht soweit alles ganz gut aus, aber rufe ich die index.php auf, bekomme ich nur eine weisse seit mit dem inhalt:

Code: Select all

Die Anfrage kann nicht beantwortet werden, da im Server ein interner Fehler aufgetreten ist. Fehlermeldung: 
Die Anfrage kann nicht beantwortet werden, da im Server ein interner Fehler aufgetreten ist. Der Server ist entweder überlastet oder ein Fehler in einem CGI-Skript ist aufgetreten.

Ich bin da echt ratlos. Es wird alles richtig ausgeführt und vhost stimmt auch, aber es bleibt weiterhin eine weisse seite :(

Kann mir da nicht noch jemand helfen??

[Joe User]

Funktioniert zumindest ein simples phpinfo()?

[blnsnoopy26]

Funktioniert zumindest ein simples phpinfo()?

Das testscript war eine phpinfo.
Das witzige ist daran, das ein script namens "test.cgi" ohne weiteres funktioniert und auch dort die suexec.log greift und alles richtig schreibt.

Ich bin nach verschieden howtos hier im forum nachgegangen sowie habe ich per google mal geschaut, aber nirgens wird das Thema so tiefgreifend behandelt.

Ich habe auch schon verschiedene chmods versucht. bei chmod 644 gibs in der suexec nur ein permission denied und bei 755 ist wieder alles ok.
Ich kann den Fehler nicht finden, weil wie gesagt in den logs ist alles korrekt. Das ist zum mäuse melken. Hatte auch mal hier im Forum bei der suche irgendwo gelesen das suexec eher was für cgi/perl scripte sein sollte.

Ich bin selbst nach dem debianhowto nachgegangen. Alles leider ohne Erfolg. Entweder mag suexec kein php oder irgendwo anders ist der Wurm drinnen. Wenn in den logs wenigstens was genaues drin stehn würde wo der Fehler liegen könnte, aber da ist absolut nichts, weil ja alles korrekt ausgeführt wird, bis auf den 500'er Error beim aufrufen der Seite.

Also ich habe hier noch was gefunden in den apachelogs. Habe nur suexec.log geschaut.

Da erscheint nur folgendes:

Code: Select all

error] [client 84.191.219.34] client denied by server configuration: /home/htdocs/web1/test/cgi-bin/index.php
error] [client 84.191.219.34] client denied by server configuration: /home/htdocs/web1/test/cgi/index.php
error] [client 84.191.219.34] Premature end of script headers: test.php

:x :? :(

Werd mich mal schlau machen was das heisst, aber ich hab hier gelesen man solle für php doch lieber suphp nutzen und für CGI Scripte dann suexec nutzen.

Ist da was wahres dran?
Wenn ich da keine Lösung finde, muss ich wohl bei suphp bleiben und alles so wie gehabt weiter machen. Wollte halt nur eine Alternative probieren.

[wgot]

Hallo,

Premature end of script headers: test.php

wenn Du PHP als (echtes) CGI aufruftst mußt Du den Content-type-header selbst senden:

Code: Select all

echo "Content-type: text/htmlnn";

chmod 755.

Als PHP kannst Du nicht die (unmodifizierte) CGI-Variante einsetzen weil diese den direkten Aufruf sperrt:

http://de3.php.net/manual/de/security.c ... direct.php

Mit der CLI-Variante ging's bei mir, allerdings ist die phpinfo dabei ohne HTML-Tags.

aber ich hab hier gelesen man solle für php doch lieber suphp nutzen und für CGI Scripte dann suexec nutzen.

Das ist erheblich problemloser, außerdem muß nicht jedes Script angepaßt werden.

Gruß, Wolfgang

[blnsnoopy26]

Hi,

Ok, dann werde ich wohl weiterhin bei Suphp bleiben und es auch weiterhin in meiner doku verwenden. Wenn das ganze über suexec komplizierter ist als mit suphp, dann sollte man nicht unbedingt das komplizierte nehmen.

Wenn es einfacher währe, als suphp, wobei für mich es kein Problem darstellt es zu kompelieren, dann währe das suexec eine alternative zu suphp.

Aber dennoch thx an alle für die mühe mir irgendwie zu helfen :) :roll: