Apache2 Worker mit PHP und fcgid (FastCGI) SuExec auf Debian Lenny
Mit diesem Thema beschäftige ich mich schon seit 2003, aber aus Bequemlichkeit habe ich darauf verzichtet. Jetzt wurde es wieder aktuell und so machte ich mich auf die Suche nach aktuellen How To's. Überraschender Weise fand ich sogar ein sehr gutes! => christophfischer Dies soll eine kurze Zusammenfassung werden damit ich beim nächsten mal nicht wieder suchen muss. 
Warum sollte man fcgid benutzen und nicht mod_php?
Warum Apache und PHP sollte klar sein, aber warum sollte man fcgid benutzen und nicht mod_php?
- PHP wird normal als Apache Nutzer ausgeführt. d.h. das jedes Script auch mit dessen Rechten ausgeführt wird. Dies kann zu Sicherheitsproblemen führen, besonders wenn man mehrere Benutzer auf einem Server hat.
- Apache legt Files als User www-data an. Wenn man nun diese Dateien als FTP User bearbeiten will geht dies nicht. Deshalb wäre es gut Dateien mit den gleichen Benutzerrechten anzulegen mit denen man auch per FTP darauf zugreifen möchte.
- mod_php kann nicht mit dem Apache MPM Worker eingesetzt werden. Deshalb muss man das recht alte und langsamere MPM Prefork benutzen. Außerdem ist PHP nicht wirklich Threadsave und man muss deshalb Prefork nutzen. Mit fcgid ist dieses Problem gelöst.
- Mit mod_php kann man nur eine php.ini für den gesamten Server anlegen, was bei unterschiedlichen Projekten oder Benutzern aber nicht immer Sinn macht. Mit fcgid kann man für jeden vhost eine eigene php.ini definieren und so mehr auf die Bedürfnisse der einzelnen Projekte eingehen.
- Es ist sogar möglich mehrere PHP Versionen auf dem gleichen Server zu verwenden! So kann ein vhost mit PHP4 laufen und ein anderer mit PHP5.
Hinweise:
- Bei großen Installationen (viele vhosts) kann es zu RAM Problemen kommen, da für jeden vhost-Apache-User mindestens 1 PHP Prozess vorgehalten wird. suPHP könnte hier besser funktionieren.
- Der erste Aufruf einer Website nach dem Start des Apaches kann etwas länger dauern, da erst der PHP Prozess in den Arbeitsspeicher geladen werden muss. Wenn er erst mal drin ist geht aber alles sehr schnell. Das betrifft aber auch nur Server mit sehr vielen vhosts!
- Fastcgi aus dem Paket libapache2-mod-fastcgi darf nicht installiert sein. Dies ist durch die Verbesserungen in fcgid veraltet und sollte nicht mehr verwandt werden.
Ich lege für jeden vhost einen eigenen System User an. So hat User X nur Rechte seine eigenen Dateien zu bearbeiten und kann nicht auf die Files von User Y zugreifen. Das ist einer der größten Vorteile beim Einsatz von SuExec und fcgid, da so auch mögliche Einbrecher im System nur einen vhost unter ihre Kontrolle bringen können und nicht das ganze System. Um es möglichst einfach zu haben benutze ich den gleichen Namen an allen möglichen Stellen! In diesem Beispiel heißt der User vh-example.
Installation:
Die Installation ist wie immer bei Debian schnell und einfach. In diesem Beispiel benutze ich das von Debian verwaltete php5 Paket, aber wie schon gesagt kann man sich auch einfach seine eigenen Paket bauen und benutzen.
$ aptitude install apache2-mpm-worker apache2-suexec php5-cgi libapache2-mod-fcgid
Noch ein paar Zusatzpakete die ich oft brauche.
$ aptitude install php5-curl php5-gd php5-mcrypt php5-mysql
Wenn PHP Kommandozeile Support gewünscht ist, dann wird das folgende Paket installiert.
$ aptitude install php5-cli
Jetzt noch die apache module fcgid und suexec aktivieren und fertig. Fertig ist man natürlich noch nicht. Damit die Änderungen wirksam werden müsste noch der Apache neu gestartet oder wenigstens die Config neu laden werden, aber da die Konfiguration ja noch fehlt lasse ich es an dieser Stelle weg.
$ a2enmod fcgid suexec rewrite
Konfiguration:
Normalerweise lege ich meine vhosts unter /www/ ab, aber da hier das SuExec Paket von Debian benutzt wird, müssen die vhosts im Debian Standard Pfad liegen (/var/www/) da dieser Pfad fest in das SuExec Paket ein kompiliert ist. Note: Möchte man den Pfad anpassen, dann ist dies anscheinden mit dem Paket apache2-suexec-custom möglich. Hiermit kann man die SuExec Config mit Hilfe der Datei /etc/apache2/suexec/www-data anpassen und somit den Pfad zu den vhosts frei wählen. Danke an tobyte für den Tipp.
Unter dem htdocs Verzeichnis lege ich noch ein public Verzeichnis an das die DocumentRoot für den Apache wird. Wenn der User sich jetzt per FTP einloggt kommt er in den htdocs Ordner und kann dann in den public Ordner. Das hat den Vorteil das er noch Dateien außerhalb seiner DocumentRoot ablegen kann, aber nicht ohne weiteres an die User Sessions oder an die Configs kommt. Meine Standard Ordner Struktur sieht so aus:
#die configs dieses vhosts /var/www/vh-example/conf #hier landet der User wenn er sich per FTP einloggt /var/www/vh-example/htdocs #das ist die DocumentRoot für den Apache /var/www/vh-example/htdocs/public #custom logs für diesen vhost /var/www/vh-example/logs #der eigene tmp Ordner /var/www/vh-example/tmp #der eigene Sessions Ordner /var/www/vh-example/sessions
Nun wird der System User erstellt.
$ useradd -s /bin/false -d /var/www/vh-example/htdocs vh-example $ adduser www-data vh-example
Mit -s /bin/false legt man fest das der User keine Standardshell hat und sich deshalb nicht auf dem System einloggen kann. -d legt das Home Directory des Users fest. Als letztes kommt der Name des Users. Die zweite Zeile fügt den User www-data (Apache User) zur Gruppe unseres neuen Users hinzu. Damit kann der Apache auf die Verzeichnisse und Dateien unseres neuen Users zugreifen. Das ist zwingend notwendig damit Webseiten ausgeliefert werden können.
Jetzt werden die Verzeichnisse des neuen vhosts angelegt.
$ mkdir -p /var/www/vh-example/htdocs/public $ mkdir /var/www/vh-example/logs /var/www/vh-example/conf $ mkdir /var/www/vh-example/sessions /var/www/vh-example/tmp
Als nächstes lege ich die vhost Config an und fülle sie mit Inhalten. Als Beispiel hier eine simple vhost Config die ich als Basis benutze.
$ nano /etc/apache2/sites-available/vh-example
<VirtualHost *:80>
ServerName example.de
ServerAdmin admin@example.de
Include /etc/apache2/mods-available/fcgid.conf
DocumentRoot /var/www/vh-example/htdocs/public
SuexecUserGroup vh-example vh-example
<Directory /var/www/vh-example/htdocs/public>
FCGIWrapper /var/www/vh-example/conf/fcgid .php
<FilesMatch \.php$>
SetHandler fcgid-script
</FilesMatch>
Options +ExecCGI -Indexes
Order allow,deny
allow from all
AllowOverride All
</Directory>
LogLevel warn
ErrorLog /var/www/vh-example/logs/error_log
CustomLog "| /usr/sbin/rotatelogs /var/www/vh-example/logs/access_log.%Y.%m.%d 86400" combined
</VirtualHost>
SuexecUserGroup: legt den User und die Gruppe fest unter der die PHP Skripte ausgeführt werden.
FCGIWrapper: legt den Pfad zum fcgid-starter fest und weist .php Dateien diesem zu.
Options +ExecCGI: erlaubt das Ausführen von PHP Dateien im CGI Modus
In der vhost Config lade ich außerdem noch einmal die fcgid.conf, da aktuell ansonsten die dort definierten Einstellungen durch die Standardwerte überschrieben werden. Eine genaue Erklärung gibt es in diesem Artikel.
Nachdem wir im vhost schon den Pfad zum fcgid starter angegeben haben, wird es Zeit ihn auch anzulegen.
$ nano /var/www/vh-example/conf/fcgid
#!/bin/sh export PHPRC="/var/www/vh-example/conf/" exec /usr/bin/php5-cgi
Die zweite Zeile weist der Variable PHPRC den Pfad zu unserem Config Verzeichnis zu. In diesem liegt auch die User php.ini und mit diesem Kommando weiß nun auch der CGI Prozess davon. Die dritte Zeile gibt an welches CGI Paket bei einem Aufruf geladen werden soll. An dieser Stelle könnte man also auch ein PHP4 oder irgend eine spezielle PHP Konfiguration einbinden.
Wie schon erwähnt können wir für jeden vhost eine eigene php.ini anbieten. Da diese nur als Ergänzung zur Standard php.ini zu sehen ist sichern wir als erstes die Standard php.ini ab. Korrektur: Scheinbar wird nicht erst die globale php.ini geladen und dann die Werte aus der User php.ini überschrieben. Es muss also in jedem vhost eine komplette php.ini liegen! Es macht aber trotzdem Sinn erst einmal die System php.ini abzusichern um eine möglichst restriktive Standardkonfiguration zu erhalten die als default genommen werden kann.
$ cp /usr/share/doc/php5-common/examples/php.ini-recommended /etc/php5/cgi/php.ini
Ich benutze als Basis die mitgelieferte php.ini-recommended. Sie ist super kommentiert falls man weitere Anpassungen vornehmen möchte. Nun können wir im conf Ordner unseres vhosts eine weitere php.ini anlegen um vom Standard abzuweichen. Leider werden eben nicht die Werte der Standard.ini mit denen der User.ini überschrieben, sondern es wird nur die User.ini geladen! d.h. das alle hier nicht angegebene Parameter auf die PHP eigenen defaults gesetzt werden. Man sollte also Vorsichtig sein und überprüfen ob man wirklich eine User.ini braucht.
$ nano /var/www/vh-example/conf/php.ini
open_basedir = /var/www/vh-example/htdocs/public:/var/www/vh-example/tmp/ upload_tmp_dir = /var/www/vh-example/tmp soap.wsdl_cache_dir = /var/www/vh-example/tmp session.save_path = /var/www/vh-example/sessions
Beim verwenden eigener Session Dirs sollte man die Session Garbage Collection Verwaltung beachten! Auf weitere php.ini Einstellungen bin ich hier näher eingegangen.
Sehr wichtig sind außerdem die richtigen Zugriffsrechte der Ordner und Dateien in unserem vhost.
| /var/www/vh-example | root:vh-example | 750 | |
| /var/www/vh-example/conf | vh-example:vh-example | 750 | |
| - php.ini | root:vh-example | 640 | (immutaple bit) |
| - fcgid | vh-example:vh-example | 750 | (immutaple bit) |
| /var/www/vh-example/htdocs | vh-example:vh-example | 750 | |
| - *.* | vh-example:vh-example | 640 | |
| /var/www/vh-example/htdocs/public | vh-example:vh-example | 750 | |
| - *.* | vh-example:vh-example | 640 | |
| /var/www/vh-example/logs | root:root | 750 | |
| /var/www/vh-example/tmp | vh-example:vh-example | 750 | |
| /var/www/vh-example/sessions | vh-example:vh-example | 750 |
Und das ganze in Befehle gefasst.
$ chown root:vh-example /var/www/vh-example
$ chmod 750 /var/www/vh-example
$ chown vh-example:vh-example /var/www/vh-example/*
$ chmod 750 /var/www/vh-example/*
$ chown root:root /var/www/vh-example/logs
$ chown root:vh-example /var/www/vh-example/conf/php.ini
$ chmod 640 /var/www/vh-example/conf/php.ini
$ chown vh-example:vh-example /var/www/vh-example/conf/fcgid
$ chmod 750 /var/www/vh-example/conf/fcgid
$ chown -R vh-example:vh-example /var/www/vh-example/htdocs
$ find /var/www/vh-example/htdocs -type d -exec chmod 750 {} +
$ find /var/www/vh-example/htdocs -type f -exec chmod 640 {} +
$ chmod 750 /var/www/vh-example/htdocs
Das Immutable Bit setzt man sobald man mit der Konfiguration fertig/zufrieden ist. Es verhindert das weiter Anpassungen an den Dateien vorgenommen werden können und da es nur von root wieder entfernt werden kann, schließt man Änderungen andere User 100% aus.
$ chattr +i -V /var/www/vh-example/conf/fcgid $ chattr +i -V /var/www/vh-example/conf/php.ini
Und so entfernt man das Immutable Bit wieder (als root).
$ chattr -i -V /var/www/vh-example/conf/fcgid $ chattr -i -V /var/www/vh-example/conf/php.ini
Bei der php.ini ist das Immutable Bit eigentlich nicht nötig, da der vhost User eh nur lesen darf, aber ich setze es trotzdem. Dann noch die Site aktivieren und den Apache neu starten.
$ a2ensite vh-example $ apache2ctl configtest $ /etc/init.d/apache2 restart
Fertig. Wenn es jetzt nicht gleich auf Anhieb funktioniert, einfach die Logs des Apaches und des vhost Users beobachten. Bei Problemen sind in 95% der Fälle die Zugriffsrechte nicht richtig gesetzt! Anmerkungen und Ergänzungen sind natürlich ausdrücklich erwünscht.
Einen weiteren vhost anlegen
Möchte man einen weiteren vhost anlegen wiederholt man die betreffenden Schritte einfach. Ich habe mir dafür eine Textdatei angelegt, in der ich nur den vhost Namen Suche und Ersetze und dann die Befehle nach einander ausführe. Damit hat man einen weiteren vhost innerhalb von 2 Minuten angelegt und einsatzbereit. Hier geht es zu der Textdatei.
Notizen:
vhost File Name: vh-example
vhost Pfad: /var/www/vh-example/
Systemuser: vh-example
Datenbankname: example
Datenbankuser: example
Datenbankpass: ***********
FTP User: example
FTP Password: *********** (nicht wie DB PW!)
58 Kommentare
mrschm
schrieb am 18.08.2009 um 13:02 Uhr
Manchmal bin ich aber auch einfach zu faul und installiere mir einen apache prefork mit php Unterstützung.
$ aptitude install apache2 php5 php5-curl
Selam
schrieb am 02.09.2009 um 10:10 Uhr
Hey du hast in der php.ini 2x den Session Pfad drin. Funktioniert zwar auch so da der zweite den ersten überschreibt, aber soll wohl nicht so sein oder?
mrschm
schrieb am 02.09.2009 um 21:58 Uhr
jo danke ist gefixt
Andreas
schrieb am 22.09.2009 um 09:40 Uhr
Und weil sich so sehr sehr sehr viele sessions in /var/www/VHOST/sessions/ ansammeln, welche vom System nicht automatisch aufgeräumt werden (siehe php.ini) habe ich /usr/lib/php5/maxlifetime und /etc/cron.d/php5 wie folgt angepasst:
/usr/lib/php5/maxlifetime
#!/bin/sh -e max=1440 for ini in /var/www/*/conf/php.ini; do cur=$(sed -n -e 's/^[[:space:]]*session.gc_maxlifetime[[:space:]]*=[[:space:]]*\([0-9]\+\).*$/\1/p' $ini 2>/dev/null || true); [ -z "$cur" ] && cur=0 [ "$cur" -gt "$max" ] && max=$cur done echo $(($max/60)) exit 0/etc/cron.d/php5
Ähm… nun ja… in einer Zeile halt, aber das gibt das Formular hier nicht her
Jedenfalls wird so nun auch wieder automatisch vom System aufgeräumt und abgelaufen sessions werden gelöscht…
Gruß,
Andreas
Andreas
schrieb am 22.09.2009 um 10:16 Uhr
Huch, jetzt erst http://www.debianroot.de/server/php-session-save_path-debian-fcgid-1029.html gesehen
Geht natürlich auch, wobei ich meinem irgendwie mehr vertraue
Nochmal Gruß!
mrschm
schrieb am 22.09.2009 um 10:31 Uhr
Hehe ich habe es mal formatiert und ist natürlich auch eine Lösung.
maXus
schrieb am 10.12.2009 um 18:35 Uhr
Du sprichst suPHP bei vielen Usern an. Welche Unterschiede gibt es hier zu deinem Vorschlag? Warum nicht gleich auf suPHP setzen?
Ansonsten scheint es auch reibungslos geklappt zu haben. Er meckerte zwar beim Apache Config Test, doch das ist ja eher das kleinere Ding:
apache2: Could not reliably determine the server’s fully qualified domain name, using (IP ausgetauscht) for ServerName
kostaki
schrieb am 10.12.2009 um 20:39 Uhr
Zu den Unterschieden von suPHP und fastcgi/fcgid will ich hier nichts schreiben, da gibt es schon genug von im Netz. Hier beschreibt jemand sehr gut warum es manchmal Sinn macht das eine oder das andere einzusetzen. Es kommt halt immer auf die Anforderungen an und bei meinen Servern ist fastcgi die bessere Wahl. Wenn du mehr Informationen suchst, dann google einfach: “suphp fastcgi”.
Das Problem mit dem “fully qualified domain name” ist leicht zu beheben. Da muss nur entweder der richtige Servername in die apache.conf oder der richtige Name in die /etc/hosts. Auch dazu gibt es unzählige Anleitungen im Netz
Marus
schrieb am 12.12.2009 um 22:58 Uhr
Sagte ja das is eher nen kleines Ding. Wollte damit sagen, dass ich weiß was los is
Dann mach ich mal weiter mit dem Ding.
tobyte
schrieb am 08.02.2010 um 10:57 Uhr
Danke für den Artikel, hat mir sehr geholfen.
Mit dem Paket apache2-suexec-custom lässt sich der Pfad für suexec übrigens auch komfortabel in der Datei /etc/apache2/suexec/www-data einstellen.
crousN
schrieb am 12.05.2010 um 20:02 Uhr
Mhm.. die Anleitung an sich ist super! Aber ich sehe sie nicht als sehr sicher an!
Denn nun darf www-data (sprich vh-example) in jedem Verzeichnis schreiben (ist ja fast einem chmod 777 ähnlich).
Sprich Bugs in Skripten oder Plugins führen direkt dazu, dass jeder User mit seinem Browser überall reinschreiben kann.
Oder sehe ich da was falsch?
kostaki
schrieb am 12.05.2010 um 20:28 Uhr
Nicht ganz. Über adduser www-data vh-example wird der User www-data in die Gruppe vh-example gesetzt. Dadurch kann www-data die Dateien von vh-example lesen.
vh-example kann nur die Dateien editieren/lesen die auch ihm gehören und das sollten in diesem Fall nur die unter /var/www/vh-example/ sein.
Die Vorteile von SuExec merke ich jetzt erst richtig. So kann man WordPress Plugins mit einem Klick installieren oder löschen und Piwik automatisch updaten lassen. Der Sicherheitsgewinn ist auch super. Wenn WordPress/anderes System kompromittiert wird, dann sollte auch nur der vhost dieses Users betroffen sein.
crousN
schrieb am 14.05.2010 um 09:05 Uhr
Mhm… stimmt! An sich hast du Recht aber:
- Zitat -
Die Vorteile von SuExec merke ich jetzt erst richtig. So kann man WordPress Plugins mit einem Klick installieren oder löschen und Piwik automatisch updaten lassen. Der Sicherheitsgewinn ist auch super. Wenn WordPress/anderes System kompromittiert wird, dann sollte auch nur der vhost dieses Users betroffen sein.
- Zitat Ende -
Genau da sehe ich ja die Schwachstelle. Die eine vHost-Benutzer hat Berechtigungen auf ihren ganzen Ordner und wird auch mit dem User ausgeführt.
Ich mein im Endeffekt ist es eigentlich egal, weil wenn man so eklatante Bugs in seinen Seiten hat wird man so oder so gehackt
Persönlich wäre es mir aber sicherer, wenn der User der es ausführt auch nur Lese Rechte hat und ich für bestimmte Ordner/Dateien nur “Schreibrechte” vergebe.
An sich ist das ganze so aber schon sicher, aber man kann ja immer mal meckern
Trotzdem sehr schönes Tutorial!
kostaki
schrieb am 14.05.2010 um 13:18 Uhr
Hm ja das ist Ansichtssache. Wenn ich einen Vhost einrichte, dann ist bei mir der User dieses Vhost für seine Dateien verantwortlich. Dabei ist mir wichtig das wenn etwas passiert keine anderen Projekte/Systeme/Vhosts dran glauben müssen. Bei einer Kompromittierung kann der Angreifer so nur Scripte mit den Rechten des Vhosts ausführen und kann somit auch nur Schaden in diesem einen Vhost anrichten. Das ist meiner Ansicht nach schon ein großer Sicherheitsgewinn.
Marco
schrieb am 18.05.2010 um 12:23 Uhr
Hey! Nettes HowTo! Hab es auch gestern schon ausprobiert und läuft prima. Jetzt wollte ich allerdings den Worker auf einem produktiven System einrichten, wo nun der Prefork mit mod_php rennt. Weiterhin nutze ich nun Webmin/Virtualmin zur Verwaltung der einzelnen Vhosts. Wie gehe ich nun am Besten vor? Würde mich da sehr über eine kleine Hilfe freuen.
Neonstriker
schrieb am 01.06.2010 um 23:16 Uhr
Ich habe ein kleines Problem:
Ich habe eine lamp version von debian, habe nun dein TuT hier befolgt nur komme ich immer wieder ins www verzeichnis wenn ich meine domain eingebe! Ich vermute mal das liegt an dem standart einstellungen:
Virtueller Server
Behandelt den Namen-basierten Server an Adresse *.
Adresse Beliebig
Port 80 Server-Name Automatisch
Dokument-Root /var/www/
Wenn ich jedoch diesen lösche bringt er mir eine fehler meldung default nicht vorhanden
Neonstriker
schrieb am 01.06.2010 um 23:24 Uhr
Desweiteren komme ich nun nicht merh auf mein phpmyadmin wenn ich dies eigebe bekomme ich ein fenster zum downloaden einer 4NCYghRA.part datei
kostaki
schrieb am 02.06.2010 um 08:25 Uhr
Sorry aber da weiß ich nicht mal wo ich anfangen soll. Da scheint etwas ganz elementares nicht zu stimmen. Hast du überhaupt eigene Vhosts angelegt oder nur den default?
Neonstriker
schrieb am 02.06.2010 um 13:07 Uhr
Also……^^
Es handelt sich um einen standart Lamp Server! Ich mache nun nichts anderes als deinen anleitung zu folgen also 1zu1 genau das selbe (natürlich mit meiner domain)! Wenn ich dies gemacht habe und auf meine domain gehen möchte komme ich quasi noch in den default verzeichnis raus also dort wo steht “It Works” und ich weis nicht weshalb! Wenn ich meine ip eingebe komme ich ebenfalls auf dieser Seite heraus jedoch komme ich weder via domain noch via up in mein phpmyadmin ich bekomme hier immer wieder nur einen download von einer datei angeboten! Wenn ich auf den webspace “www” eine html lege funktioniert das jedoch bei einer php funktioniert dies nicht da kommt nun der download. Natürlich kann ich es nicht mit meiner domain testen da ich ja nicht ins richtige verzeichniss gelange also var/www/test/htdocs/public sondern ich komme immer iweder in var/www/
kostaki
schrieb am 02.06.2010 um 17:05 Uhr
Vielleicht ne Dumme Frage, aber hast du mal den Apache neu gestartet? Sieht mir so aus als ob die Config(s) nicht geladen werden… Du hast ja sicher eine vhost Config unter /etc/apache2/sites-available/, in der /var/www/test/htdocs/public steht. Ich sage mal vh-test. Die hast du dann aktiviert mit a2ensite vh-test und dann den Apache neu gestartet /etc/init.d/apache2 restart. Das PHP Dateien als Download angeboten werden liegt meist auch an der Konfiguration des Webservers. Hier scheint PHP nicht richtig konfiguriert zu sein. Ein Blick in die log Files unter /var/logs/ könnte auch helfen.
Neonstriker
schrieb am 02.06.2010 um 17:40 Uhr
Ich hab meinen fehler gefunden^^ oder zumindest denke ich das! Wäre supi wenn ihr das nochmal bestätigen könnt das ich so doof war.
/etc/apache2/sites-available/kdt-wow-hp
ich dachte da muss
stehen bleiben! Nun hab ich das geändert in
und es funzt! nun hab ich nur das Problem, das ich immer noch nicht auf mein Phpmyadmin komme bzw wenn ich nun über meine ip auf die Seite möchte kommt dieses download fenster bei jeglichen php seiten! Wie ich ja gesehen habe hatte dieses Problem schoneinal jemand bei der einrichtung des phpmyadmins! vorher hat alles funktioniert nur seit dieser anleitung gehen quasi keine php scripte ehr unter dem standart vhost
Neonstriker
schrieb am 02.06.2010 um 18:57 Uhr
VirtualHost *:80
geändert in
VirtualHost domain.de:80
Neonstriker
schrieb am 02.06.2010 um 23:06 Uhr
AddHandler fcgid-script .php
für was diesnt dies eigentlich das finde ich in jeder anleitung außer hier
kostaki
schrieb am 03.06.2010 um 08:26 Uhr
Das findest du hier auch im in der Vhost Config im FilesMatch \.php$ Block. Wenn PHP Scripte zum Download angeboten werden, dann weiß der Webserver nicht was er damit anfangen soll. Es muss also irgend etwas fehlen.
Ulrich
schrieb am 08.06.2010 um 07:58 Uhr
@Neonstriker:
Du musst einen eigenen Vhost für phpmyadmin anlegen und diesen dann auf /user/share/phpmyadmin legen.
Wie das geht habe hier hier erklärt:
http://www.ulrich-block.de/?p=3
Neonstriker
schrieb am 24.06.2010 um 22:04 Uhr
Schau mal du hast bei open_basedir vergessen dein sessiondir einzutragen wenn ich mich nicht täusche! Soweit ich das in erinnerung habe sollte das dabei stehen
kostaki
schrieb am 25.06.2010 um 08:45 Uhr
Hi ich habe es nicht drin zu stehen und es funktioniert. Ich habe aber seit langem keine PHP Sessions mehr benutzt (ich benutze MySQL oder Memcached), deshalb bin ich mir nicht 100% sicher! Wenn das jemand bestätigen kann, passe ich es an.
traxxus
schrieb am 02.07.2010 um 07:19 Uhr
Hallo
Bei mir will das einfach nicht laufen. Hab schon zig mal Debian neu installiert aber es ist IMMER der gleiche Fehler. PHP Dateien bietet er mir zum Downlaod an anstatt sie auszuführen.
HAbe das Tutorial von Christophfischer sehr genau befolgt. Mit diesem Tutorial hier ist es dasselbe Ergebnis.
Habe echt keine Ahnung woran es scheitert.
kostaki
schrieb am 02.07.2010 um 08:54 Uhr
Das die Dateien zum Download angeboten werden heißt das der Webserver nicht weiß was er mit ihnen machen soll. Also entweder ist PHP nicht installiert oder der Webserver nicht richtig konfiguriert in der Verwendung von PHP. Wenn ich einen neuen Webserver einrichte, dann gehe ich eigentlich nur diese Liste 1:1 durch und verändere den vhostnamen und es funktioniert jedes mal. Als Anhaltspunkte wo man mal schauen kann:
– Webserver neu gestartet nach der Konfiguration?
– hast du schon mal in die Apache Logfiles geguckt?
traxxus
schrieb am 02.07.2010 um 09:14 Uhr
Webserver ist natürlich neu gestartet worden, selbst Debian.
Was geb ich denn in der vhost config an wenn ich gar keine Domain besitze und nur per IP bzw. DynDNS Adresse auf die Website gehe?
kostaki
schrieb am 02.07.2010 um 15:36 Uhr
einen vhost hast du ja immer, das wäre dann der default vhost. Der muss so ausgestattet werden wie oben beschrieben. Schau einfach mal in den /etc/apache2/sites-enabled/ Ordner.
traxxus
schrieb am 05.07.2010 um 14:58 Uhr
Konnte es lösen. Ich musste noch folgendes ausführen:
apt-get install libapache2-mod-php5
Danach werden die PHP Dateien ausgeführt.
kostaki
schrieb am 05.07.2010 um 15:04 Uhr
Das ist dann aber mod_php und kein php via fcgid!
traxxus
schrieb am 05.07.2010 um 16:47 Uhr
Trotz 1:1 Befolgung oben ging’s erst nach Installation des genannten Pakets….
ka was ich falsch mache.
traxxus
schrieb am 24.08.2010 um 18:02 Uhr
Ich nochmals
Dein Tut funzte nicht einmal bei 5 Installationsversuchen. Dieses hier haut sofort hin:
http://www.howtoforge.com/how-to-set-up-apache2-with-mod_fcgid-and-php5-on-debian-lenny
Vielleicht solltest du dir das mal ansehen?
kostaki
schrieb am 24.08.2010 um 20:18 Uhr
Hey traxxus
Schade das es bei dir nicht funktioniert.
Kann mir so ohne Infos leider nicht erklären warum das so ist… Ich weiß aber recht genau das diese Anleitung hier funktioniert, weil ich sie selbst bei jedem neuen Webserver mit Apache2-fcgid benutze.
Sobald Squeeze stable wird, werde ich sie aber noch einmal komplett überarbeiten und wenn nötig anpassen. Als viel Erfolg noch.
olafson
schrieb am 28.02.2011 um 17:52 Uhr
Hosa
ich bekomme nach deiner Anleitung immer ein
You don’t have permission to access /vh-example/htdocs/index.php on this server.
Hab alle Permissions so wie in deiner Anleitung
gesetzt.
kostaki
schrieb am 01.03.2011 um 09:18 Uhr
Schau nochmal über alles rüber. Auch ob die Pfade stimmen und natürlich die Berechtigungen. Hast du den vhost wirklich vh-example genannt oder ist das nur copy&paste Fehler?
Sebastian
schrieb am 28.03.2011 um 14:00 Uhr
Moin!
Danke erstmal für das nette Tut!
Ein Problem hab ich allerdings…
Wenn ich nun so Dinge wie zB phpmyadmin installiere, erstellt der Installer im Order /etc/apache2/conf.d/ eine Datei mit der Konfiguration der entsprechenden Anwendung. In dem Fall phpmyadmin.
Da ich aber für die ganzen allgemeines Apps eine eigene Subdomain einrichte und somit auch meine vhost configs selbst schreiben will, frage ich mich ob ich den include vom ‘conf.d’ Ordner in der apache2.conf einfach auskommentieren kann oder hat das anderweitige folgen?!
Wenn ich die files einfach lösche sind sie nach dem nächsten update wieder da, weil der Installer denkt die Datei würde fehlen.
Vielen Dank für die Hilfe oder zumindest einen Denkanstoss!
Gruß
Sebastian
kostaki
schrieb am 28.03.2011 um 15:01 Uhr
Lass sie doch einfach da und mach sie leer oder kommentiere die Zeilen aus. Der Paketmanager sollte dann beim Update des Paketes fragen ob er die Config anpassen soll und da musst du dann nur nein sagen.
Sebastian
schrieb am 31.03.2011 um 10:32 Uhr
Hallo
Super Tutorial seit mehre Wochen läuft mein Server mit der Konfiguration.
Nun habe ich leider aber ein Problem, ich muss ein paar .html Seiten als php ausführen lassen. Dazu habe ich mir .htaccess Datei mit folgenden Inhalt erstellt:
AddHandler application/x-httpd-php .html
in der Apache Konfiguration für vhost steht auch AllowOverride All.
Trotzdem werden die html Seiten nicht als php geparst. Ich bin am verzweifeln. Woran kann das liegen.
Schöne Grüße
Sebastian
kostaki
schrieb am 31.03.2011 um 12:18 Uhr
Hab ioh noch nicht gemacht, aber guck ma in die vhost Config. Dort gibt es ja Stellen mit .php und die müsstest du sicher auch noch anpassen/erweitern.
newbie
schrieb am 17.07.2011 um 13:00 Uhr
Hi, ich hab mal versucht es nach dieser Anleitung um zusetzten, hat nicht ganz geklappt. Wenn ich eine *.php Datei im Verzeichnis aufrufe lädt er mir einfach nur das Skript runter.
Server version: Apache/2.2.16 (Debian)
PHP 5.3.3-7+squeeze3
Ich komme nicht weiter, hat jemand eine Idee was man machen könnte in den log Dateien steht auch nicht wirklich was drin.
kostaki
schrieb am 19.07.2011 um 08:22 Uhr
Hi, das klingt danach das irgend ein Pfad falsch ist oder irgend welche Rechte falsch gesetzt sind. Mehr kann man so ins blaue nicht sagen. Einfach noch einmal alles überprüfen.
wynni
schrieb am 11.08.2011 um 20:00 Uhr
Tools howto. Wie kann ich nun testen ob das auch mit diesem User ausgeführt wird?
Danke
wynni
kostaki
schrieb am 12.08.2011 um 06:32 Uhr
Bau dir ein Script das versucht auf eine Datei zuzugreifen auf die der User keine Rechte hat und dann auf eine auf die er Rechte hat. Dann kannst du noch per Script eine Datei erstellen lassen und gucken welchen owner/group diese bekommt.
wynni
schrieb am 18.08.2011 um 19:21 Uhr
wie hast das mit dem ftp server gelöst? du hast ja “useradd -s /bin/false” da kann man sich ja mit diesem user nicht anmelden. Hast du die user über mysql, dann fehlen wieder die rechte auf den htdocs ordner… was verstehe ich hier nicht?
kostaki
schrieb am 19.08.2011 um 07:49 Uhr
Ich benutze pureftpd wie hier beschrieben.
http://www.debianroot.de/server/ftp-server-pureftpd-mit-mysql-und-tls-unterstuetzung-1014.html
Accounts brauchen da keine Shell, damit es funktioniert.
DefCon
schrieb am 19.09.2011 um 11:34 Uhr
Vorweg, sehr nette und super Anleitung (Neudeutsch: Tutorial)!
Ich habe irgendwie das Gefühl das wenn ich einen Webserver so aufbaue wie du es oben beschreibst, sich ein Chroot für Apache an sich erübrigt? Oder bin ich da auf dem Holzweg? Da ein Angreifer ja nicht weiter kann als das vhost Verzeichnis. (Aufgrund der Rechte) Andere Frage: Das ganze ist portierbar auf Debian 6 (Squezze)?
Viele Grüße,
Marcus
kostaki
schrieb am 19.09.2011 um 11:42 Uhr
Ja ist portierbar auf Squeeze. Einige Sachen funktionieren etwas anders.
– die php.ini recommended liegt wo anders
– das braucht man nicht mehr in jedem vhost Include /etc/apache2/mods-available/fcgid.conf
– die fcgid.conf benutzt andere Werte
Ein Angreifer hat wenn er einen vhost unter seine Kontrolle bringt nur die Rechte dieses Vhost Users. Er kann also auch nur mit dessen Rechten Schaden anrichten.
DefCon
schrieb am 19.09.2011 um 12:19 Uhr
Hey! Danke für die schnelle Antwort!
Ich werde dann mal beginnen das bei mir nach zu bauen.
Drückt mir die Däumchen.
Greetz
timwebdev
schrieb am 21.10.2011 um 12:02 Uhr
Hi,
ich versuche mich gerade an der Installation mehrerer PHP Version unter Squeeze. Ich habe den Artikel hier gefunden http://stackoverflow.com/questions/524508/how-can-one-run-multiple-versions-of-php-5-x-on-a-development-lamp-server welcher aber nur für Ubuntu geeignet ist. Wie kann ich denn mehrere Repositories mit unterschiedlichen PHP Versionen eintragen und vorallem, wie kann ich diese für die jeweilige Version installieren?
Ideal ist natürlich eine Verzeichnisstruktur, bspw.
/usr/bin/php5.2
/usr/bin/php5.3
oder ähnliches …
Ich hoffe ich habe bei der Suche hier und über Google nichts vercheckt. Kann mir dabei jemand behilflich sein oder einen Tipp geben?
Viele Grüße
kostaki
schrieb am 21.10.2011 um 12:08 Uhr
Das ist natürlich möglich per fastcgi! Die Frage ist nur wo du die php binaries her bekommst. Fertige Debian Repos die auch ältere Versionen beinhalten sind mir nicht bekannt. Du kannst sie dir natürlich selbst kompilieren.
timwebdev
schrieb am 21.10.2011 um 16:12 Uhr
Danke für die schnelle Antwort!
Hab ich mir schon gedacht und selber kompilieren ist nicht so elegant.
Sascha
schrieb am 24.10.2011 um 14:03 Uhr
Hallo,
danke erst mal für das ausführliche Tut.
Bei mir wollte das ganze erst fliegen, als ich den sessions und tmp Ordnern noch die entspechenden Benutzer und Gruppen zugewiesen habe. Soweit ich das in Deinem Tut sehe, bleiben die unberührt und gehören dem Ersteller (in meinem Fall dem root). Ergo hat die gestartete PHP-Instanz keine Berechtigung, die Sessions zu schreiben.
kostaki
schrieb am 26.10.2011 um 07:42 Uhr
Hi,
die müssen natürlich dem User gehören. Steht so eigentlich auch in der Rechte Tabelle und die Befehle darunter machen dies auch