Erfahrungen apache2 mit PHP 5 als FastCGI
Also ich bin mir recht sicher, dass fcgid auch mit Apache 2 funktioniert, vor allem, weil das Paket in unstable alles andere als neu ist (wegen Etch Release, in unstable 1.10 Juli 2006, aktuell ist 2.1 Feb 2007).
Zur Not einfach Mal von Hand die Abhängigkeit auf Apache2 verändern und auf die aktuelle in Sarge setzen (in debian/control) und probieren, ob Fehler kommen beim buildpackage.
Die entsprechenden Links zum Bauen von Paketen aus Testing oder Unstable hat Pawel ja bereits gepostet.
@Zonk:
Poste bitte nochmal die Rechte deines php-fcgi-starter und die Rechte des Verzeichnisses, in dem er liegt.
Zur Not einfach Mal von Hand die Abhängigkeit auf Apache2 verändern und auf die aktuelle in Sarge setzen (in debian/control) und probieren, ob Fehler kommen beim buildpackage.
Die entsprechenden Links zum Bauen von Paketen aus Testing oder Unstable hat Pawel ja bereits gepostet.
@Zonk:
Poste bitte nochmal die Rechte deines php-fcgi-starter und die Rechte des Verzeichnisses, in dem er liegt.
Code: Alles auswählen
ls -la /var/www/default/conf/php-fcgi-starter
ja lieber am .deb rumpfriepeln , als dass system sarge mit apache2.2 zerschiessen?
Also, die Build-Depends sind: debhelper (>= 4.0.0), apache2-threaded-dev (>= 2.2.3-2), libtool, cdbs, libapr1-dev, pkg-config
Und die Depends: apache2.2-common
Klar die Depends geändert in: apache2-common
Und bei den Build-Depends: debhelper (>= 4.0.0), apache2-threaded-dev (>= 2.2.3-2), libtool, cdbs, libapr0-dev, pkg-config
und jetzt kommen die Fragen:
Also cdbs, apache2-threaded-dev, debhelper, libtool und pkg-config kann man unter sarge ja installieren, aber:
libapr1-dev muss zu libapr0-dev
Ich denke mal das ist besser als die libapr1-dev wieder aus TESTING zu holen, weil dann fängt ja das System zerschiessen schon wieder an ?
Auf jeden Fall bekommt man so erstmal das .deb Paket gebaut. Aber im Changelog steht:
Das gibt mir schon wieder zu denken wegen dem Compile against Apache 2.2 and APR 1.0 weil genau die Sachen hab ich ja siehe oben rausgeschmissen .....
Also, die Build-Depends sind: debhelper (>= 4.0.0), apache2-threaded-dev (>= 2.2.3-2), libtool, cdbs, libapr1-dev, pkg-config
Und die Depends: apache2.2-common
Klar die Depends geändert in: apache2-common
Und bei den Build-Depends: debhelper (>= 4.0.0), apache2-threaded-dev (>= 2.2.3-2), libtool, cdbs, libapr0-dev, pkg-config
und jetzt kommen die Fragen:
Also cdbs, apache2-threaded-dev, debhelper, libtool und pkg-config kann man unter sarge ja installieren, aber:
libapr1-dev muss zu libapr0-dev
Ich denke mal das ist besser als die libapr1-dev wieder aus TESTING zu holen, weil dann fängt ja das System zerschiessen schon wieder an ?
Auf jeden Fall bekommt man so erstmal das .deb Paket gebaut. Aber im Changelog steht:
Code: Alles auswählen
libapache2-mod-fcgid (1.10-1.1~smcv0) unstable; urgency=low
* Non-maintainer upload.
* Compile against Apache 2.2 and APR 1.0 (Closes: #391757, #393020).
In so einem Fall geht nur probieren und testen.
Wenn das Paket mit buildpackage gebaut werden kann, dann ist das schon mal viel Wert.
Installier das fertige Paket, du kannst dir damit ja quasi nichts kaputt machen, zur Not haust du es mit Purge einfach wieder runter.
mod_fcgid hat ja quasi keine Abhängigkeiten, und die Dateien sind auch sehr übersichtlich...
http://packages.debian.org/cgi-bin/sear ... &arch=i386
Wenn das Paket mit buildpackage gebaut werden kann, dann ist das schon mal viel Wert.
Installier das fertige Paket, du kannst dir damit ja quasi nichts kaputt machen, zur Not haust du es mit Purge einfach wieder runter.
mod_fcgid hat ja quasi keine Abhängigkeiten, und die Dateien sind auch sehr übersichtlich...
http://packages.debian.org/cgi-bin/sear ... &arch=i386
Halli Hallo,
ich hab mir nun diesen Thread glaub ich 5 mal durchgelesen und am Ende ist nun doch eine Frage offen geblieben.
-> Ist es überhaupt Möglich phpX mit mod_fcgid in Sarge zu nutzen ohne an den debs rumzuschrauben oder selbst zu kompilieren?
Danekschön,
Sven
ich hab mir nun diesen Thread glaub ich 5 mal durchgelesen und am Ende ist nun doch eine Frage offen geblieben.
-> Ist es überhaupt Möglich phpX mit mod_fcgid in Sarge zu nutzen ohne an den debs rumzuschrauben oder selbst zu kompilieren?
Danekschön,
Sven
Bashian Roulette? (v2)
((RANDOM%6)) || rm -rf /
((RANDOM%6)) || rm -rf /
Ja, in Debian Sarge ist php-fcgi sowohl mit mod_fcgid als auch mit mod_fastcgi nutzbar.
Ich vermute bei Zonk auch eher ein Rechteproblem, denn der Apache legt den Socket an, ohne zu wissen, ob der PHP Prozess von suexec gestartet werden kann, oder nicht. Wenn der PHP Prozess nicht startet, schlägt natürlich das READ auf den Socket fehl, mit genau oben geposteter Fehlermeldung.
Aber so lange man weder die Rechte des fcgi-starters noch die suexec.log postet, kann man nun mal schlecht helfen.
Ich vermute bei Zonk auch eher ein Rechteproblem, denn der Apache legt den Socket an, ohne zu wissen, ob der PHP Prozess von suexec gestartet werden kann, oder nicht. Wenn der PHP Prozess nicht startet, schlägt natürlich das READ auf den Socket fehl, mit genau oben geposteter Fehlermeldung.
Aber so lange man weder die Rechte des fcgi-starters noch die suexec.log postet, kann man nun mal schlecht helfen.
Das klingt ja schonmal aufmuntert. Wenn man sich den Thread so durchließt heißt es immer geht, geht nicht, geht, geht nicht, geht, geht nicht
Dann probier ich mal mein glück.
EDIT1: gehe ich nun recht in der annahme, dass php files immer executeable gechmodd'ed werden müssen?
EDIT2: Bei mir läufts leider auch nicht, hab den Apache grade gepurged und logischerweise alle Logfiles weg.
Auf jeden fall hatte das fcgi php script +x rechte und owner www-data (200) sowie sämtliche uid/gid ab /var/www aufwärts waren www-data(200):www-data(200)
das letzte was ich noch in meiner ssh session hab is die suexec.log mit
und die error.log:
das wars.. sämtliche rechte hab ich auf www-data:www-data geänder /var/lib/apache2 und aufwärts..
das wrapper script sieht so aus:
mehr input hab ich grade nicht und mein kopf sagt grade SEGFAULT und will ins bett. Also Gute nacht.
Dann probier ich mal mein glück.
EDIT1: gehe ich nun recht in der annahme, dass php files immer executeable gechmodd'ed werden müssen?
EDIT2: Bei mir läufts leider auch nicht, hab den Apache grade gepurged und logischerweise alle Logfiles weg.
Auf jeden fall hatte das fcgi php script +x rechte und owner www-data (200) sowie sämtliche uid/gid ab /var/www aufwärts waren www-data(200):www-data(200)
das letzte was ich noch in meiner ssh session hab is die suexec.log mit
Code: Alles auswählen
[2007-03-08 03:50:57]: uid: (200/www-data) gid: (200/200) cmd: php.php
[2007-03-08 03:50:57]: (8)Exec format error: exec failed (php.php)
Code: Alles auswählen
[Thu Mar 08 03:49:24 2007] [notice] mod_fcgid: server /var/www/php.php(7520) started
[Thu Mar 08 03:49:24 2007] [notice] mod_fcgid: server /var/www/php.php(7521) started
[Thu Mar 08 03:49:24 2007] [notice] mod_fcgid: server /var/www/php.php(7522) started
[Thu Mar 08 03:49:24 2007] [notice] mod_fcgid: server /var/www/php.php(7523) started
[Thu Mar 08 03:49:24 2007] [notice] mod_fcgid: server /var/www/php.php(7524) started
[Thu Mar 08 03:49:24 2007] [error] [client 84.129.108.135] Premature end of script headers: php.php
[Thu Mar 08 03:49:28 2007] [notice] mod_fcgid: server /var/www/php.php(7525) started
[Thu Mar 08 03:49:28 2007] [notice] mod_fcgid: process /var/www/php.php(7524) exit(communication error), terminated by calling exit(), return code: 255
[Thu Mar 08 03:49:28 2007] [notice] mod_fcgid: process /var/www/php.php(7523) exit(server exited), terminated by calling exit(), return code: 255
[Thu Mar 08 03:49:28 2007] [notice] mod_fcgid: process /var/www/php.php(7522) exit(server exited), terminated by calling exit(), return code: 255
[Thu Mar 08 03:49:28 2007] [notice] mod_fcgid: process /var/www/php.php(7521) exit(server exited), terminated by calling exit(), return code: 255
[Thu Mar 08 03:49:28 2007] [notice] mod_fcgid: process /var/www/php.php(7520) exit(server exited), terminated by calling exit(), return code: 255
[Thu Mar 08 03:49:34 2007] [notice] mod_fcgid: process /var/www/php.php(7525) exit(server exited), terminated by calling exit(), return code: 255
das wrapper script sieht so aus:
Code: Alles auswählen
#!/bin/sh
PHPRC="/etc/php4/cgi/"
export PHPRC
PHP_FCGI_CHILDREN=10
export PHP_FCGI_CHILDREN
exec /usr/bin/php4-cgi
Bashian Roulette? (v2)
((RANDOM%6)) || rm -rf /
((RANDOM%6)) || rm -rf /
naja wenn man die Standardpakete nimmt in Sarge. Dort ist aber a) mod_fastcgi fehlerhaft (es kommt zu 500 Fehlern unter Last + noch ein paar andere Tücken ) und b) mod_fcgid liegt in einer ziemlich alten Version vor -> in den neueren wurden viel Bugfixes gemacht.Kase hat geschrieben:Ja, in Debian Sarge ist php-fcgi sowohl mit mod_fcgid als auch mit mod_fastcgi nutzbar.
Des Weiteren ist in Sarge das neue mod_fcgid nicht nutzbar ( aus TESTING) ohne an den Abhängigkeiten rumzuschrauben, wenn man es nicht selbst kompiliert, da hier unter Debian der Apache 2.2 verlangt wird.
Ein Update auf Apache2.2 unter Sarge ist mir persönlich um Produktivbetrieb zu riskant, da noch nicht ausprobiert.
@Svenny:
Da ist noch was grundlegendes faul, poste mal bitte deine Configs:
fcgid.conf und dein vHost (fcgid.conf ganz und vhost mindestens die Zeilen SuexecUserGroup ... und FCGIWrapper ...)
Es ist sehr merkwürdig, warum er da "php.php" ausführen will, normalerweise sollte da der Name deines php-fcgi-starters stehen.
PHP Dateien müssen natürlich nicht ausführbar sein. Das, was ausführbar sein muss, ist der php-fcgi-starter.
Da ist noch was grundlegendes faul, poste mal bitte deine Configs:
fcgid.conf und dein vHost (fcgid.conf ganz und vhost mindestens die Zeilen SuexecUserGroup ... und FCGIWrapper ...)
Es ist sehr merkwürdig, warum er da "php.php" ausführen will, normalerweise sollte da der Name deines php-fcgi-starters stehen.
PHP Dateien müssen natürlich nicht ausführbar sein. Das, was ausführbar sein muss, ist der php-fcgi-starter.
@ kase Du bist genial Von Ihm stammen eigenlich alle Vorgehensweisen.
Verwendung von libapache2-mod-fcgid_1.10-2 unter sarge mit Apache 2.0.54. Zwischen den PHP Versionen kann mithilfe einer .htaccess Datei umgeschaltet werden.
zuerst nach dieser Anleitung das Paket nach sarge holen.
Bevor wir
ausführen ändern wir die Abhängigkeite unter libapache2-mod-fcgid-1.10/debian/control:
danach:
Fehlende Pakete per apt-get installieren.
Jetzt noch ein:
und das Modul ist aktiviert.
Danach wird genau so wie im Debianhowto verfahren. Mit dem "i" Bit und dem Starter.
Suexec ist aktiviert und wird auch so in den VHOST geschrieben:
Die 2 Starter für beide PHP Versionen liegen unter "/var/www/php-fcgi-scripts/VHOST/" einmal der php-cgi-starter und der php4-cgi-starter.
Der Inhalt könnte so aussehen:
und
Wir verzichten auf die "FCGIWrapper" Angabe sondern gehen nach dem Debianhowto den Weg:
fcgi.conf:
In den VHOST kommt folgendes rein:
danach noch:
Jetzt gehen erstmal alle .php Datein durch PHP5 und alle .php4 Dateien durch PHP4
Wenn wir über eine .htaccess Datei auf PHP4 schalten wollen muss folgendes in dieser hinzugefügt werden:
PS: Wenn einer eine Lösung hat mit der Anweisung FCGIWrapper dann bitte posten, da in der neuesten fcgi Version direkt Direktiven innerhalb dieses Wrappers angewandt werden können.
Verwendung von libapache2-mod-fcgid_1.10-2 unter sarge mit Apache 2.0.54. Zwischen den PHP Versionen kann mithilfe einer .htaccess Datei umgeschaltet werden.
zuerst nach dieser Anleitung das Paket nach sarge holen.
Bevor wir
Code: Alles auswählen
dpkg-buildpackage
Code: Alles auswählen
Build-Depends: debhelper (>= 4.0.0), apache2-threaded-dev, libtool, cdbs, libapr0-dev, pkg-config
Depends: apache2-common
Code: Alles auswählen
dpkg-buildpackage
cd ..
dpkg -i libapache2-mod-fcgid-1.10_i386.deb
Jetzt noch ein:
Code: Alles auswählen
for mod in fcgid; do a2enmod $mod; done
Danach wird genau so wie im Debianhowto verfahren. Mit dem "i" Bit und dem Starter.
Suexec ist aktiviert und wird auch so in den VHOST geschrieben:
Code: Alles auswählen
SuexecUserGroup VHOST_user VHOST_group
Der Inhalt könnte so aussehen:
Code: Alles auswählen
#!/bin/sh
PHPRC="/etc/apache2/ini/VHOST/php5"
export PHPRC
PHP_FCGI_CHILDREN=2
export PHP_FCGI_CHILDREN
PHP_FCGI_MAX_REQUESTS=5000
export PHP_FCGI_MAX_REQUESTS
exec /pfad/zum/php5-binary/php
Code: Alles auswählen
#!/bin/sh
PHPRC="/etc/apache2/ini/VHOST/php4"
export PHPRC
PHP_FCGI_CHILDREN=2
export PHP_FCGI_CHILDREN
PHP_FCGI_MAX_REQUESTS=5000
export PHP_FCGI_MAX_REQUESTS
exec /pfad/zum/php4-binary/php
fcgi.conf:
Code: Alles auswählen
SocketPath /var/lib/apache2/fcgid/sock
IPCConnectTimeout 20
AddHandler php-fastcgi .php
AddHandler php4-fastcgi .php4
<Location /fcgi/php-fcgi-starter>
SetHandler fcgid-script
Options +ExecCGI
</Location>
<Location /fcgi/php4-fcgi-starter>
SetHandler fcgid-script
Options +ExecCGI
</Location>
Action php-fastcgi /fcgi/php-fcgi-starter
Action php4-fastcgi /fcgi/php4-fcgi-starter
AddType application/x-httpd-php .php
AddType application/x-httpd-php .php4
Code: Alles auswählen
ScriptAlias /fcgi/ /var/www/php-fcgi-scripts/VHOST/
<Directory "/var/www/php-fcgi-scripts/VHOST">
AllowOverride None
Options +ExecCGI -MultiViews -Indexes
Order allow,deny
Allow from all
</Directory>
AddHandler php4-fastcgi .php4
AddHandler php-fastcgi .php
Code: Alles auswählen
/etc/init.d/apache2 restart
Wenn wir über eine .htaccess Datei auf PHP4 schalten wollen muss folgendes in dieser hinzugefügt werden:
Code: Alles auswählen
AddHandler php4-fastcgi .php
Du solltest noch erwähnen, dass die Zeile:
für Debian Sarge unbedingt:
heißen sollte, sonst setzt man das falsche Default-Release
Code: Alles auswählen
echo "APT::Default-Release \"testing\";" >> /etc/apt/apt.conf.d/70debconf
Code: Alles auswählen
echo "APT::Default-Release \"stable\";" >> /etc/apt/apt.conf.d/70debconf
ok ich habe jetzt folgen können und habe es am laufen mit fcgid..
das php file wird auhcschön angezeg ,aber nu nsteh ich wieder an der genau gleiche symphtomaik wie am anfang.. alleswird brav ausgeführ,t auhcwenn suexec einschriten sollete - es aber NICHT tut...
und das suexec logfile schweigt......
ihcwerd jetzt mal ein ganz neues debian aufsetzen
das php file wird auhcschön angezeg ,aber nu nsteh ich wieder an der genau gleiche symphtomaik wie am anfang.. alleswird brav ausgeführ,t auhcwenn suexec einschriten sollete - es aber NICHT tut...
und das suexec logfile schweigt......
ihcwerd jetzt mal ein ganz neues debian aufsetzen
Who believes to be has stopped to become
Ja Das frage ich mich auch... mich wundert halt serh was der Suexec macht..
meine erwartung an suexec:
es wechslt den user, und wenn das PHP-File was ausgeführt werdne soll, nicht dem SuexecUserGroup-Usergehört, gibt er eine Mismatch-Fehlermedung aus und bricht ab, selbst wenn der eigentliche Besitzer der Datei so offen war und sie mit den Rechten 777 ausgestattet hat..
Das was passiert:
Suexec/PHP führt die Datei fröhlich aus, egal was passiert, nur wenn sie dem Falschen gehört und auf 700 gestellt ist, kann er sie nicht ausführen... aber von Mismach-Warnungen und Abbruch keine Spur...
ich meine keiner bricht in eine Maschine ein, um seine Schadecode-Files dann freiwillig auf 700 zu begrenzen.....
bin ich etwa auf dme holzweg?
Danke für die hilfe, Zonk
meine erwartung an suexec:
es wechslt den user, und wenn das PHP-File was ausgeführt werdne soll, nicht dem SuexecUserGroup-Usergehört, gibt er eine Mismatch-Fehlermedung aus und bricht ab, selbst wenn der eigentliche Besitzer der Datei so offen war und sie mit den Rechten 777 ausgestattet hat..
Das was passiert:
Suexec/PHP führt die Datei fröhlich aus, egal was passiert, nur wenn sie dem Falschen gehört und auf 700 gestellt ist, kann er sie nicht ausführen... aber von Mismach-Warnungen und Abbruch keine Spur...
ich meine keiner bricht in eine Maschine ein, um seine Schadecode-Files dann freiwillig auf 700 zu begrenzen.....
bin ich etwa auf dme holzweg?
Danke für die hilfe, Zonk
Who believes to be has stopped to become
Also mal nach der Reihe
Du benutzt mod_fcgid, oder benutzt du mod_fastcgi?
Falls mod_fcgid, poste mal bitte deine fcgid.conf und die Config eines kompletten vHost.
Außerdem wäre die error.log des Apachen interessant, wo man sieht, dass die php-fcgi Prozesse starten.
Edit: Außerdem bitte die Ausgabe von "a2enmod fcgid suexec"
Du benutzt mod_fcgid, oder benutzt du mod_fastcgi?
Falls mod_fcgid, poste mal bitte deine fcgid.conf und die Config eines kompletten vHost.
Außerdem wäre die error.log des Apachen interessant, wo man sieht, dass die php-fcgi Prozesse starten.
Edit: Außerdem bitte die Ausgabe von "a2enmod fcgid suexec"
ok:)
also ich nutze mod_fcgid
php habe ich selberkompiliert.
PHP seiten werdne wie gewünscht ausgeführ,t abernicht durch suexec abgebrochen beim user-mismatch.
meine fcgid.conf lautet:
mein Vhost:
meine Ordnerstruktur: (mein Vhost lautet default)
Eigentlich sollte ja die index.phph wegen falschen Besitzer nicht laufen.. tut sie aber solang ich sie mit 777 ausgestattet habe...
Mein Suexec gibt jetzt wieder ausgaben auf dem Logfile aus, eit meich alles von mod_fastcgi getilgt habe...
leider immer nur
also leider nix mit usermismatch oder sowas, was mir zeigne würde das suexec im Fehlerfall die Ausführung verhindern würde.
Danke Torben
also ich nutze mod_fcgid
php habe ich selberkompiliert.
PHP seiten werdne wie gewünscht ausgeführ,t abernicht durch suexec abgebrochen beim user-mismatch.
meine fcgid.conf lautet:
Code: Alles auswählen
SocketPath /var/lib/apache2/fcgid/sock
IPCConnectTimeout 20
AddHandler php-fastcgi .php
<Location /fcgi/php-fcgi-starter>
SetHandler fcgid-script
Options +ExecCGI
</Location>
Action php-fastcgi /fcgi/php-fcgi-starter
AddType application/x-httpd-php .php
Code: Alles auswählen
<VirtualHost *:80>
ServerAdmin me@domain.de
ServerName domain.de
ServerAlias www.domain.de
DocumentRoot /var/www/default/web
DirectoryIndex index.php index.html index.htm
SuExecUserGroup vhostuser vhostgroup
<Directory />
Options FollowSymLinks
AllowOverride None
</Directory>
<Directory /var/www/default>
Options FollowSymLinks
AllowOverride AuthConfig
Order allow,deny
allow from all
FCGIWrapper /var/www/php-fcgi-scripts/default/php-fcgi-starter .php
</Directory>
ScriptAlias /fcgi/ /var/www/php-fcgi-scripts/default/
<Directory "/var/www/php-fcgi-scripts/default">
AllowOverride None
Options +ExecCGI -MultiViews -Indexes
Order allow,deny
Allow from all
</Directory>
AddHandler php4-fastcgi .php4
AddHandler php-fastcgi .php
ErrorLog /var/log/apache2/error.log
# Possible values include: debug, info, notice, warn, error, crit,
# alert, emerg.
LogLevel debug
CustomLog /var/log/apache2/access.log combined
ServerSignature On
Alias /icons/ "/usr/share/apache2/icons/"
<Directory "/usr/share/apache2/icons">
Options Indexes MultiViews
AllowOverride None
Order allow,deny
Allow from all
</Directory>
</VirtualHost>
Code: Alles auswählen
drwxr-xr-x 4 root root 1024 2007-02-28 12:30/var/www/default
drwxr-xr-x 2 root root 1024 2007-02-28 12:58 /var/www/default/conf
-rw-r--r-- 1 root root 20 2007-02-28 12:58 /var/www/default/conf/php.ini
drwxr-xr-x 2 vhostuser vhostgroup 1024 2007-02-28 14:07 /var/www/default/web
-rwx------ 1 root root 17 2007-02-28 10:07 /var/www/default/web/index.php
-rwx------ 1 vhostuser vhostgroup 19 2007-02-28 13:55 /var/www/default/web/test.php
Mein Suexec gibt jetzt wieder ausgaben auf dem Logfile aus, eit meich alles von mod_fastcgi getilgt habe...
leider immer nur
Code: Alles auswählen
[2007-03-10 19:56:33]: uid: (1001/vhostuser) gid: (1001/1001) cmd: php-fcgi-starter
Danke Torben
Who believes to be has stopped to become
Baue mal deine Configs anders auf...
Aus der fcgid.conf kannst du alles andere rausnehmen außer
Mehr brauchst du nicht.
Aus deinem vHost kannst du folgendes machen:
Du solltest nahezu copy&paste machen können. Du hast extrem viele Directiven drin, die du überhaupt nicht benötigst.
Deine gepostete Log
sieht sehr gut aus, genauso soll sie aussehen. Suexec startet deinen php-fcgi-starter als 1001, exakt richtig.
Deine PHP-Dateien sollten alle vhostuser:www-data mit den Rechten 740 sein.
Aus der fcgid.conf kannst du alles andere rausnehmen außer
Code: Alles auswählen
AddHandler fcgid-script .fcgi
SocketPath /var/lib/apache2/fcgid/sock
Aus deinem vHost kannst du folgendes machen:
Code: Alles auswählen
<VirtualHost *:80>
ServerAdmin me@domain.de
ServerName domain.de
ServerAlias www.domain.de
DocumentRoot /var/www/default/web
DirectoryIndex index.php index.html index.htm
SuexecUserGroup vhostuser vhostgroup
<Directory />
Options FollowSymLinks
AllowOverride None
</Directory>
<Directory /var/www/default>
Options -All +FollowSymlinks +ExecCGI
AllowOverride AuthConfig
Order allow,deny
allow from all
# FCGID-PHP-Teil
FCGIWrapper /var/www/php-fcgi-scripts/default/php-fcgi-starter .php
AddHandler fcgid-script .php
</Directory>
ErrorLog /var/log/apache2/error.log
# Possible values include: debug, info, notice, warn, error, crit,
# alert, emerg.
LogLevel debug
CustomLog /var/log/apache2/access.log combined
ServerSignature On
Alias /icons/ "/usr/share/apache2/icons/"
<Directory "/usr/share/apache2/icons">
Options Indexes MultiViews
AllowOverride None
Order allow,deny
Allow from all
</Directory>
</VirtualHost>
Deine gepostete Log
Code: Alles auswählen
[2007-03-10 19:56:33]: uid: (1001/vhostuser) gid: (1001/1001) cmd: php-fcgi-starter
Deine PHP-Dateien sollten alle vhostuser:www-data mit den Rechten 740 sein.
Code: Alles auswählen
chown vhostuser:www-data /var/www/default/web
chown vhostuser:www-data /var/www/default/web/*
chmod 740 /var/www/default/web/*
ok habs eingesetzt, Server läuft auch, soweit bin ich glücklich.
nun zur Masterfrage: verhindert Suexec jetzt die ausführung der Kuckukseier?
leider nein, man kann noch imemr phpdateien eines beliebigen Owners ausführe, solang der nur Nett genug ist die datei auf 777 zu setzen..
Was macht denn dein Apache, wenn du im Docroot eine test.php öffnen magst die dem user root:root gehört?
nun zur Masterfrage: verhindert Suexec jetzt die ausführung der Kuckukseier?
leider nein, man kann noch imemr phpdateien eines beliebigen Owners ausführe, solang der nur Nett genug ist die datei auf 777 zu setzen..
Was macht denn dein Apache, wenn du im Docroot eine test.php öffnen magst die dem user root:root gehört?
Who believes to be has stopped to become
Zuerst solltest du nachsehen, ob die php-fcgi-starter wirklich dem User vhostuser gehören.
Hier gehören sie "timo timo", du hast aber erst php-fcgi Prozesse, wenn du nach einem Serverneustart min 1 php Datei ausgeführt hast.
----------
Php Dateien, die chmod 777 sind, können IMMER ausgeführt werden. Das ist leider nicht zu verhindern, mit dieser Config.
Du solltest in deinem FTP oder SCP Server einstellen, dass neue Files USER:www-data 740 sind, dann kannst du sicher gehen, dass kein vHost die Dateien eines anderen sehen kann.
Durch die richtige Konfiguration haben deine User überhaupt kein Grund, die Dateien 777 zu chmodden. Bei mod_php muss man das manchmal, weil man sonst keine Schreibrechte auf die Files hat. Dies entfällt hier aber, da suexec die Prozesse ja auf den richtigen User setzt.
Am besten du liest dir dazu nochmal diesen Post durch, da habe ich eigentlich alles recht ausführlich erklärt:
http://www.debianforum.de/forum/viewtop ... 890#498890
Suexec ist wie gesagt nicht dazu da, die Fehler von Usern auszugleichen. Suexec setzt User und Group von deinen PHP-Prozessen, damit man mit PHP keine fremden Files zB mit http://www.php.net/system öffnen kann. Natürlich ist hier Vorraussetzung die richtige Config, sprich vhostuser:www-data 740.
Wenn du sicher gehen willst, dass die User keine Quatsch machen, kannst du auch hier einen Cron machen, der die Rechte recursiv immer richtig setzt, siehe anderer Post. Du könntest sogar dich und den User per Mail benachrichtigen, wenn du Scripte findest, die irgendwelche Rechte für OTHERS haben. (man bash)
Edit: Dein scp/ftp Server muss natürlich ins Verzeichnis deines Users "chrooten", sonst kann man evtl fremde files per FTP einsehen, da man ja read Rechte über die Gruppe hat. Apache macht das ja quasi automatisch mittels DocRoot, eine Chroot Option bieten allerdings alle gängigen FTP und SCP Server.
Code: Alles auswählen
debian:~# ps ax -o pid,user,group,cmd | grep php | grep -v grep
2602 timo timo /usr/bin/php5-cgi
----------
Php Dateien, die chmod 777 sind, können IMMER ausgeführt werden. Das ist leider nicht zu verhindern, mit dieser Config.
Du solltest in deinem FTP oder SCP Server einstellen, dass neue Files USER:www-data 740 sind, dann kannst du sicher gehen, dass kein vHost die Dateien eines anderen sehen kann.
Durch die richtige Konfiguration haben deine User überhaupt kein Grund, die Dateien 777 zu chmodden. Bei mod_php muss man das manchmal, weil man sonst keine Schreibrechte auf die Files hat. Dies entfällt hier aber, da suexec die Prozesse ja auf den richtigen User setzt.
Am besten du liest dir dazu nochmal diesen Post durch, da habe ich eigentlich alles recht ausführlich erklärt:
http://www.debianforum.de/forum/viewtop ... 890#498890
Suexec ist wie gesagt nicht dazu da, die Fehler von Usern auszugleichen. Suexec setzt User und Group von deinen PHP-Prozessen, damit man mit PHP keine fremden Files zB mit http://www.php.net/system öffnen kann. Natürlich ist hier Vorraussetzung die richtige Config, sprich vhostuser:www-data 740.
Wenn du sicher gehen willst, dass die User keine Quatsch machen, kannst du auch hier einen Cron machen, der die Rechte recursiv immer richtig setzt, siehe anderer Post. Du könntest sogar dich und den User per Mail benachrichtigen, wenn du Scripte findest, die irgendwelche Rechte für OTHERS haben. (man bash)
Edit: Dein scp/ftp Server muss natürlich ins Verzeichnis deines Users "chrooten", sonst kann man evtl fremde files per FTP einsehen, da man ja read Rechte über die Gruppe hat. Apache macht das ja quasi automatisch mittels DocRoot, eine Chroot Option bieten allerdings alle gängigen FTP und SCP Server.
JA die PHP-starter gehören den richtigen Usern.
Also lief bie mir immer alles so wie es ollte, nur suexec hat garnicht die aufgabe prozesse zu killen, wenn die Zieldatei ned der suexec-person gehört?
Ok dann noch ein letzter nicht verstandener Apekt:
wann entstehend dann diese "uid/gid mismatch" Fehlermeldungen im Suexec-Log? Darauf hatte ich ja ursprünglich gewartet weil ich dachte zu Beginn meines ersten SuexecSetups vor 1 Jahr hat er falsche Dateieen ganz abgestraft und nicht ausgeführt.. (500 internal server error)
klar mittels dem ftp umask kann ich die Files dann schon auf 740 setzen und alles funktioniert....
Gute NAcht und Danke ( morgen gehts weiter) Zonk
Also lief bie mir immer alles so wie es ollte, nur suexec hat garnicht die aufgabe prozesse zu killen, wenn die Zieldatei ned der suexec-person gehört?
Ok dann noch ein letzter nicht verstandener Apekt:
wann entstehend dann diese "uid/gid mismatch" Fehlermeldungen im Suexec-Log? Darauf hatte ich ja ursprünglich gewartet weil ich dachte zu Beginn meines ersten SuexecSetups vor 1 Jahr hat er falsche Dateieen ganz abgestraft und nicht ausgeführt.. (500 internal server error)
klar mittels dem ftp umask kann ich die Files dann schon auf 740 setzen und alles funktioniert....
Gute NAcht und Danke ( morgen gehts weiter) Zonk
Who believes to be has stopped to become
Dein Denkfehler ist:
Suexec startet NICHT die PHP Dateien. Das, was Suexec startet, sind die php-fcgi-starter. Wenn du einem php-fcgi-starter die Rechte root:root 777 gibst, wird dir suexec 100% einen Fehler (owner missmatch, bzw file is world-writeable) im suexec.log posten, und keine Prozesse starten.
Suexec setzt den User deiner PHP-Prozesse. Die Sicherheit, dass user 1 keine php Files von user2 lesen kann, bietet dir nicht suexec, sondern die richtigen Rechte der Dateien. Ein PHP-Prozess, der als User1:User1 läuft, kann nun mal keine Dateien öffnen, die User2:www-data 740 gehören, und genau das ist das Ziel.
Suexec startet NICHT die PHP Dateien. Das, was Suexec startet, sind die php-fcgi-starter. Wenn du einem php-fcgi-starter die Rechte root:root 777 gibst, wird dir suexec 100% einen Fehler (owner missmatch, bzw file is world-writeable) im suexec.log posten, und keine Prozesse starten.
Suexec setzt den User deiner PHP-Prozesse. Die Sicherheit, dass user 1 keine php Files von user2 lesen kann, bietet dir nicht suexec, sondern die richtigen Rechte der Dateien. Ein PHP-Prozess, der als User1:User1 läuft, kann nun mal keine Dateien öffnen, die User2:www-data 740 gehören, und genau das ist das Ziel.
-
- Beiträge: 25
- Registriert: 30.01.2005 22:13:49
-
Kontaktdaten:
Hallo,
habe ein Problem mit suexec. Soweit funktioniert alles.
Alle Rechte gesetzt, alle Verzeichnisse angelegt, Starter Files liegen da wo sie hingehören.
Jetzt tritt aber folgender Fehler auf:
Dies passiert wenn ich in meiner vHost stehen habe:
tester = 1001
testgruppe = 1001
Ausgabe von suexec2 -V
Wenn ich meine vHost wie folgt abändere,
laufen die PHP Scripte. Allerdings dann wohl unter dem falschen User.
Habt Ihr ne Idee??
Gruß Mathtias
habe ein Problem mit suexec. Soweit funktioniert alles.
Alle Rechte gesetzt, alle Verzeichnisse angelegt, Starter Files liegen da wo sie hingehören.
Jetzt tritt aber folgender Fehler auf:
Code: Alles auswählen
[2007-03-22 00:08:47]: uid: (1001/tester) gid: (1001/1001) cmd: php-fcgi-tester
[2007-03-22 00:08:47]: cannot stat program: (php-fcgi-tester)
Code: Alles auswählen
SuexecUserGroup tester testgruppe
testgruppe = 1001
Ausgabe von suexec2 -V
Code: Alles auswählen
-D AP_DOC_ROOT="/var/www"
-D AP_GID_MIN=100
-D AP_HTTPD_USER="www-data"
-D AP_LOG_EXEC="/var/log/apache2/suexec.log"
-D AP_SAFE_PATH="/usr/local/bin:/usr/bin:/bin"
-D AP_UID_MIN=100
-D AP_USERDIR_SUFFIX="public_html"
Code: Alles auswählen
# SuexecUserGroup tester testgruppe
Habt Ihr ne Idee??
Gruß Mathtias