Mit suPHP, PHP in Confixx für User nicht abstellbar

[overfly]

Hallo,

ich weiss nicht, ob es schonmal jmd. aufgefallen ist (ich hab hier nix gefunden), aber mit suPHP kann ich die Leistung PHP in Confixx nicht mehr deaktivieren. Sprich, da Confixx mod_php Verwendet hat jeder User automatisch PHP, da die suphp_engine ja auf on steht auch wenn ich es ihm nicht zuweise. mod_php ist ja komplett deaktiviert (evtl. bis auf den Confixx vhost).

Mit folgendem Script, was jede Minute läuft, habe ich dieses Problem umgangen:

Code: Select all

#!/bin/sh
sed 's/php_admin_flag engine off/RemoveHandler .php .php4/g' /etc/apache/confixx_vhost.conf > /etc/apache/confixx_real_vhost.conf
chmod 400 /etc/apache/confixx_real_vhost.conf
/etc/init.d/apache reload

[EDIT: Das Script hat nur 4 Zeilen: /etc/apache/confixx_real_vhost.conf muss natürlich noch hinter etc/apache/confixx_vhost.conf >. Zumindest bei 1024x768 macht er da einen Zeilenumbruch]

Am Ende der Datei /etc/apache/httpd.conf wird dann natürlich confixx_real_vhost.conf inkludiert.

Zur Erklärung:

Confixx deaktiviert am Beginn der confixx_vhost.conf mod_php innerhalb der Directory Direktive. Diesen String ersetze ich und entferne einfach den PHP Handler. Schön wäre natürlich, wenn man suphp einfach abschalten könnte, aber 'suPHP_engine off' ist leider nur global oder innerhalb der VirtualHost Direktive erlaubt.

Vielleicht nicht die eleganteste Lösung, aber mir viel nichts besseres ein. Vielleicht hat jmd. einen Verbesserungsvorschlag dazu?

*auf Uhr guck* Gute Nacht!

Christoph

[overfly]

Guten morgen,

heute morgen hatte ich dank dem Script über 800 Mails in meinem Postfach. Daher eine kleine Ã?nderung:

Code: Select all

#!/bin/sh

# Festlegen der Variablen
CONFIXX_OLD=/etc/apache/confixx_vhost.conf.old
CONFIXX_NEW=/etc/apache/confixx_vhost.conf
CONFIXX_REAL=/etc/apache/confixx_real_vhost.conf

# Wenn das Script zu ersten Mal gestartet wird, ist noch keine alte Confixx Conf vorhanden.
# Daher testen wir, ob die Datei da ist, wenn nicht wird sie angelegt.
test -x $CONFIXX_OLD || touch $CONFIXX_OLD

# Wir bilden von der aktuellen und der alten Confixx vhost Datei eine Prüfsumme
MD5SUM_OLD=`md5sum $CONFIXX_OLD | cut -b1-32`
MD5SUM_NEW=`md5sum $CONFIXX_NEW | cut -b1-32`

# Hier wird die Prüfsumme verglichen, ist sie gleich, dann beende das Programm,
# wenn nicht, dann ersetze in der confixx_vhost.conf php_admin_flag engine off
# durch RemoveHandler .php .php4 und speichere das Ergebnis in confixx_real_vhost.conf
# Rechte anpassen und den Apache seine Konfiguration neu einlesen lassen.
if [ "$MD5SUM_OLD" = "$MD5SUM_NEW" ]; then

exit 0

else

sed 's/php_admin_flag engine off/RemoveHandler .php .php4/g' $CONFIXX_NEW > $CONFIXX_REAL
cp $CONFIXX_NEW $CONFIXX_OLD
chmod 400 $CONFIXX_REAL $CONFIXX_OLD
/etc/init.d/apache reload

fi

Christoph

[bluefox]

hi christoph!

wow, super lösung! hab mich auch schon mal mit der thematik beschäftigt und hab dann auch ein skript gebastelt, was die suphp engine ausschalten sollte, bis mir dann am ende bei den testdurchläufen aufgefallen ist, dass eben wie du schon sagtest, das ganze sich nicht für die vhosts steuern läßt :( naja...

echt sehr empfehlenswert dein posting!

vielen dank!

gruß, chris

[ce2901]

wieso test -x wenn du ein chmod 400 machst? dann wird doch immer getouched? Beabsichtigt? Ich hab's bei mir in ein test -r geändert, jetzt wird nur noch getouched, wenn nix da ist oder sich was geändert hat.


Viel wichtiger jedoch: Ich hab das Skript in meinem Cron (root), wird minütlich geprüft.

Klappt alles, aber die Zeile mit /etc/init.d/apache reload wird einfach nicht ausgeführt, der Rest jedoch perfekt.

Woran kann das liegen? Ich seh's im error_log von apache, wenn ich von Hand die Zeile eintippe, klappt's. Im Skript nicht.


???

ce2901

[overfly]

Was hat denn test mit chmod zu tun?

Es wird geprüft ob die Datei vorhanden ist. Wenn nicht wird sie angelegt. Und die Rechte setz ich jedes mal aufs neue, damit die Rechte immer richtig gesetzt werden.

Zu dem anderen Problem: ka :P

[ce2901]

Nun, du machst einen chmod 400, danach hat das File nur noch Read-Rechte.
Da wäre doch ein test -r angebrachter als ein test -x? Ist nur Kosmetik, aber sonst wird halt ständig getouched und das Datum ändert sich.

Und: Da gibt es noch ein Problem, das ich für mich gefixed habe: /etc/init.d/apache reload tat nicht, wenn's per crontab aufgerufen wurde, weil der PATH nicht passend war. Habe ich gelöst durch ein export PATH=/sbin:$PATH

ce2901

[overfly]

Siehste mal, das kommt davon, wenn man von anderen Start-Scripts klaut und nicht die manpage von test liest :lol:

[mr_fish]

Ã?berlege mir auch gerad, ob ich suPHP installieren soll. Die Ausgangsfrage und -lösung dieses Threads würde mich also auch interessieren. Auf der suPHP-Hompage steht im Changelog sowas hier:

• Changes in version 0.2
  - Added support for (de-)activation for each VirtualHost defined in the Apache configuration
  - Added support for different php.ini's, configurable in the Apache config

Das deutet doch darauf hin, dass man für jede einzelnen VirtualHost suPHP (und damit auch PHP??? - Das wäre die Frage) abschalten kann ...

Hab mich noch nicht weiter mit suPHP beschäftigt, aber hat das jemand schon gemacht, oder ist das oben beschriebene Skript die beste Lösung?

Noch ne weitere Frage: suPHP funktioniert ja nur mit PHP als CGI, aber greift bei PHP als CGI nicht schon der Zugriffsschutz des Dateisystems (trotz Safe-Mode OFF)? Was ist der Vorteil von suPHP? Ich will ja lediglich ein sicheres Dateisystem haben und Safe-Mode ausschalten.

[overfly]

Ã?berlege mir auch gerad, ob ich suPHP installieren soll. Die Ausgangsfrage und -lösung dieses Threads würde mich also auch interessieren. Auf der suPHP-Hompage steht im Changelog sowas hier:

• Changes in version 0.2
  - Added support for (de-)activation for each VirtualHost defined in the Apache configuration
  - Added support for different php.ini's, configurable in the Apache config

Das deutet doch darauf hin, dass man für jede einzelnen VirtualHost suPHP (und damit auch PHP??? - Das wäre die Frage) abschalten kann ...

Hab mich noch nicht weiter mit suPHP beschäftigt, aber hat das jemand schon gemacht, oder ist das oben beschriebene Skript die beste Lösung?

Dafür ist das Script ja da. Confixx unterstützt ausschließlich mod_php. Wenn du also in den 'Confixx'-vhosts php deaktivieren willst und suphp verwendest, nimm das Script.

[mr_fish]

Hab's jetzt erst mal so laufen, dass ich über die Confixx-Funktion Httpd-Spezial in den Hosts, die kein PHP haben sollen suPHP ausschalte. Ist ein bisschen Handarbeit. Deshalb nimm ich vielleicht doch dein Script ;-)

Noch ne Frage zum Script: Sollte nicht außer

Code: Select all

RemoveHandler .php .php4 

auch noch

Code: Select all

suPHP_Engine off 

eingefügt werden? Oder ist das überflüssig?

[overfly]

Dazu bitte die Doku von suphp lesen:

suPHP_Engine (can either be turned "on" or "off")

[...]

This directive can be used in the global context or in a <VirtualHost>-directive.

Code: Select all

php_admin_flag engine off

welches durch das Script ersetzt wird steht aber in einem <Directory> Container. Ist zwar nicht ganz sauber so, aber läuft und anders gehts nicht

[eagle2k]

ich experimentire grad mit einer lösung mittels httpdspezial herum.

normalerweise müsste folgender code funktionieren:

Code: Select all

update kunden set httpdspezial = 'suPHP_engine off' where kunde = 'web0';
update allgemein set httpd='1', httpdupdate=0;

stattdessen wird scheinbar der benutzer gelöscht !?!

probiert es dochmal aus und gebt rückmeldung. die informationen habe ich aus der entsprechenden phpdatei im admin ordner.

edit:
Ich habe inzwischen eine lauffähige Version hinbekommen. Wer also wissen möchte, wie man suPHP direkt im vHost deaktivieren kann, der gucke hier:
http://www.jonaspiela.de/papers/confixx_suphp.html

[overfly]

Noch ein kleiner Bugfix zu meinem Script für Confixx 2.0:

Sobald man über Confixx einen WebXX User löscht wird nach einer gewissen Zeit der Apache neu gestartet bzw. sofort danach, je nach Confixx-Einstellung.

Zu diesem Zeitpunkt kann es sein, dass mein Script noch nicht durchgelaufen ist, sodass der Apache mit VirtualHost Einstellungen hochgefahren wird, die eigentlich gar nicht mehr existieren.

Folge: Der Apache beendet sich.

In dem Bugfix (eigentlich mehr eine Notlösung) wird jetzt zusätzlich noch geprüft, ob der Apache läuft oder nicht, falls nicht, wird er neugestartet.

Code: Select all

#!/bin/sh

CHECK_APACHE=`ps -A | grep apache`

if [ "$CHECK_APACHE" = "" ]; then

/etc/init.d/apache stop
sleep 2
/etc/init.d/apache start

fi

CONFIXX_OLD=/etc/apache/confixx_vhost.conf.old
CONFIXX_NEW=/etc/apache/confixx_vhost.conf
CONFIXX_REAL=/etc/apache/confixx_real_vhost.conf

# Wenn das Script zu ersten Mal gestartet wird, ist noch keine alte Confixx Conf vorhanden.
# Daher testen wir, ob die Datei da ist, wenn nicht wird sie angelegt.
test -r $CONFIXX_OLD || touch $CONFIXX_OLD

MD5SUM_OLD=`md5sum $CONFIXX_OLD | cut -b1-32`
MD5SUM_NEW=`md5sum $CONFIXX_NEW | cut -b1-32`

if [ "$MD5SUM_OLD" = "$MD5SUM_NEW" ]; then

exit 0

else

sed 's/php_admin_flag engine off/RemoveHandler .php .php4/g' $CONFIXX_NEW > $CONFIXX_REAL
cp $CONFIXX_NEW $CONFIXX_OLD
chmod 400 $CONFIXX_REAL $CONFIXX_OLD
/etc/init.d/apache reload

fi

Für Vorschläge, wie man das eleganter lösen kann, wäre ich dankbar :-)


Viele Grüße

OverFly