Debian Sarge, Apache2, Suexec2, mod_fastcgi, php5-fcgi HowTo

[kase]

In der error.log vom Apachen steht zu diesem Ereignis:

(2)No such file or directory: FastCGI: stat() of "/usr/lib/cgi-bin/php-fcgi-starter" failed

Dort steht doch der Fehler...
Irgendwo hast du angegeben, dass dein php-fcgi-starter Script in /usr/lib/cgi-bin/ ist, wo es aber nicht ist, wenn du zu 100% nach dem Howto vorgegangen bist.

Wo das nun genau der Fall ist, kann ich dir aber nicht zu 100% sagen. Eine Möglichkeit wäre, dass dein ScriptAlias im vHost falsch ist, allerdings ist das zu 100% im Howto richtig dargestellt. Vielleicht solltest du das Howto ein bischen genauer lesen, sollte dies der Fall sein...

Code: Select all

ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/

wird im Howto, Punkt 9, erster "Kasten" geändert in

ScriptAlias /cgi-bin/ /var/www/php-fcgi-scripts/VHOST/

Dort "könnte" wie gesagt der Fehler liegen, ist jetzt aber mehr oder weniger auf die "Schnelle" geraten. Durchsuch einfach mal deine wichtigen Config-Files nach "/usr/lib/cgi-bin"...

Edit: Bitte den Post nicht persönlich nehmen wegen dem genauer lesen, aber ich bekomme teilweise sehr viele E-Mails auf das Howto, wo es sich fast durchweg um irgendwelche Lese- oder Tippfehler handelt, das ist auf Dauer ganz schön nervig *fggggggg*

[Anonymous]

Ich habe jetzt meinen Fehler gefunden: Er hat meinen neuen VHOST nicht geladen, da da ein kleiner aber entscheindender Syntaxfehler war. Es funktioniert jetzt einwandfrei.

Vielen Dank für dein HowTo.

Meyma

[darkcloud14]

s.h. http://www.rootforum.org/forum/viewtopi ... 777#214777

[tix.64]

deb http://ftp.debian.de/debian stable main
deb-src http://ftp.debian.de/debian stable main
deb http://ftp.debian.de/debian-non-US stable/non-US main
deb-src http://ftp.debian.de/debian-non-US stable/non-US main
deb http://security.debian.org/ stable/updates main
deb-src http://security.debian.org/ stable/updates main
deb http://security.debian.org/ woody/updates main contrib non-free

deb ftp://ftp.serverkompetenz.de/debian stable main contrib non-free
deb-src ftp://ftp.serverkompetenz.de/debian stable main contrib non-free

Dieses Howto ist für Debian Sarge. Das ist der testing-Zweig. Der ist in deiner sources.list nicht vorhanden.

tix.64

[darkcloud14]

Hmpf gibts irgendwo ein script mit dem ich Debian Sarge auf meinem Root Server installieren kann ??

Hmpf ich werd mal die Suchen Funktion nutzen ;)

[kase]

In deiner sources.list sämtliche stable/woody Einträge durch testing/sarge ersetzen, danach ein "apt-get update && apt-get dist-upgrade" ausführen. Wichtig ist, dass dieser Vorgang wohl nicht auf Anhieb klappen wird, und danach wohl noch sehr viel Handarbeit gemacht werden muss. Umso "frischer" dein Woody System ist, desto weniger Probleme sollte es geben. Natürlich ist bei sowas ein Backup UNBEDINGT notwendig, denn unter Umständen kann es passieren, dass du dir dein System zerschiesst.

Ich wäre dir allerdings sehr dankbar, wenn du diesen Thread hier nicht mit dem Thema ins Off-Topic ziehen würdest, benutz google und die Suchfunktion, oder mache einen extra Thread auf.

[darkcloud14]

Hmm soweit so gut :D Es funktioniert soweit alles wobei ich bei mir das ganze auf PHP4 basis konfiguriert habe...

[carl]

bei mir funktionieren alle php-scripte die HTTP authentication verwenden nicht korrekt. es erscheint zwar die dialogbox zur eingabe des passwortes, das korrekte passwort wird jedoch nicht akzeptiert. habe ich irgendwas vergessen in mein php mitrein zu compilieren?

[kenzo]

http://php3.de/manual/de/features.http-auth.php (1. Satz)

[kase]

Der Antwort von Kenzo gibt es nichts hinzuzufügen. Bitte auf andere Authorizationen ausweichen. (Cookies, Sessions, usw) Bei phpMyAdmin und Cookie-Auth darauf achten, dass man den Cookie-Crypt-String in der config.inc.php nicht vergisst, ansonsten wird es nicht funktionieren.

[deeluxe]

Hey ihr!

Also erstmal besten Danke für das Howto, dass funzt echt spitze. Nun aber zu meinem Problem. Irgendwie will mein phpmyadmin damit aber nicht richtig laufen! Habt ihr ne Ahnung was folgendee Fehler zu bedeuten hat?

Code: Select all

Strict Standards: var: Deprecated. Please use the public/private/protected modifiers in /var/www/www.***.de/web/phpmyadmin/libraries/blowfish.php on line 36

Strict Standards: var: Deprecated. Please use the public/private/protected modifiers in /var/www/www.***.de/web/phpmyadmin/libraries/blowfish.php on line 101

Strict Standards: var: Deprecated. Please use the public/private/protected modifiers in /var/www/www.***.de/web/phpmyadmin/libraries/blowfish.php on line 166

Strict Standards: var: Deprecated. Please use the public/private/protected modifiers in /var/www/www.***.de/web/phpmyadmin/libraries/blowfish.php on line 231

Strict Standards: var: Deprecated. Please use the public/private/protected modifiers in /var/www/www.***.de/web/phpmyadmin/libraries/blowfish.php on line 298

Warning: Cannot modify header information - headers already sent by (output started at /var/www/www.***.de/web/phpmyadmin/libraries/blowfish.php:28) in /var/www/www.***.de/web/phpmyadmin/libraries/auth/cookie.auth.lib.php on line 108

Warning: Cannot modify header information - headers already sent by (output started at /var/www/www.***.de/web/phpmyadmin/libraries/blowfish.php:28) in /var/www/www.***.de/web/phpmyadmin/libraries/select_theme.lib.php on line 92

Ich hab die Rechte schon überprüft, eigentlich alles gemacht, aber ich finde keinen Fehler! Muss also was mit phpmyadmin sein! Ich benutze die neuste phpmyadmin Version!

Wäre nett wenn mir einer von euch helfen könnte!

edit: achso, der crypt string ist gesetzt

mfg Tobi

[kase]

Dein Problem ist das error_logging. Du benutzt scheinbar php5, phpmyadmin wurde aber für php4 programmiert. Da du sogar "strict-Errors" aktiviert hast, bekommst du deswegen Errors angezeigt, da es in php5 in Klassen "var $var" nicht mehr gibt. (nur noch public/protected/private $var)

=> Dein Error-Logging so ändern, dass strict Errors deaktiviert sind, du musst dies nicht global machen, es reicht, wenn du es für phpmyadmin deaktivierst.

[deeluxe]

Jau Danke! Es funzt!

Jetzt zu meinem nächsten Problem! Mein Apache schmiert auf unerklärlich Art und Weise bei ca. 60 usern auf der Page immer ab. Er rennt dann zwar noch, bearbeitet aber keine Anfragen mehr, woran kann das liegen!

Edit: Folgender Fehler ist in der Error Log zu finden:

Code: Select all

(2)No such file or directory: FastCGI: failed to connect to server "/var/www/php-fcgi-scripts/www.***.de/php-fcgi-starter": connect() failed, referer: .......

Also muss der Fehler mit dem Fcgi kram zusammenhängen! Falls jemand eine Antwort hat, bitte schnell bescheid sagen

mfg Tobi

[kase]

Das ist äußerst merkwürdig...

60 User sind normal "nichts" für fastcgi, daran liegt es auf keinen Fall.

Auf welchen Wert hast du die PHP_FCGI_CHILDREN Var gesetzt? Versuch sie mal auf 1 zu setzen oder sogar ganz wegzulassen (oder mal stark zu erhöhen, auf 40 oder so). Vielleicht läuft es dann besser. Ansonsten wäre es natürlich interessant zu wissen, welche Datei er nicht findet. IMHO geht es aus deinen geposteten Logs nicht hervor.

Unter Umständen ist es auch ein Problem mit deinen FastCGI Streams, über die der Apache mit fastCGI kommuniziert. Vielleicht hast du irgendwelche Dateien in /var/run gelöscht? (oder die Partition /var ist voll??)

Schau dir mal ein

Code: Select all

netstat -ap | grep "fastcgi"

an, wenn der Apache normal läuft, und wenn diese Error-Meldung kommt.

Ansonsten hilft vielleicht noch ein "strace" auf den Apache oder einen fastcgi Prozess.

[deeluxe]

Das komische ist, dass das die einzige Fehlermeldung ist. Sie wiederholt sich bei jeder Verbindung aufs neue! Habe die Children vom fcgi jetzt mal auf 20 hochgeschraubt und bis jetzt hält der Server. Hoffen wir mal, dass er nun stable ist :). Falls es Probleme gibt oder ich ne Lösung gefunden habe, meld ich mich nochmal!

mfg Tobi

[kase]

Bei 50+ Usern gleichzeitig empfehle ich aus eigenen Erfahrungen auch einen Wert von um die 20, bei einem Server mit 100+ Usern gleichzeitig kann durchaus ein Wert von 30 gewählt werden. Oder man nimmt die Alternative von Kenzo und lässt die Var ganz raus, damit PHP es vollkommen alleine verwaltet.

[deeluxe]

Heyho!

Also mit der Umstellung auf mehrere fcgi childs hat der Apache schon mal besser gehalten. Ist nur trotzdem wieder abgeschmiert. Es kommt mir so vor als ob er irgendwie hängen bleibt. Hab nun heute 30 fcgi childs im Test, aber ist das nicht ein bischen überdimensioniert???

Edit: Mir ist noch was aufgefallen. Irgendwie hat ein php-fcgi child immer eine sehr sehr hohe CPU Auslastung, bzw. benutzt vielm CPU Power!!!

mfg Tobi

[kase]

Die Auslastung ist nicht weiter schlimm, zumindest, wenn sie nicht über längere Zeit anhält. Komplexere PHP Scripte haben auch bei mir kurzzeitig mal 100% CPU.

30 Children ist schon recht viel für "läppische" 60 User. Es ist sehr wichtig, dass du, sollte dieser Fehler nochmal auftreten, du 1. den netstat Befehl ausführst, und schaust, ob die dynamic Streams noch vorhanden sind im Modus "LISTENING", und du mal ein "ps aux | grep fcgi" machst, und schaust, wie viele fcgi Prozesse "wirklich" vorhanden sind. Vielleicht hast du das gleiche Problem wie Kenzo, dass der Apache weitere Children unaufgefordert nachspawnt, und deswegen alles in die Knie geht.

=> Sollte das Problem nachmals auftreten, poste hier bitte die Ausgabe von:

netstat -ap | grep "fastcgi"
ps aux | grep "fcgi"

und auch ein "strace" auf einen Apache Prozess oder einen fcgi Prozess, vielleicht finden wir dort ein paar weitere Informationen. Normalerweise kommt deine Fehlermeldung, wenn man die dynamischen FastCGI Prozesse löscht, denn dann löscht man die Schnittstelle und der Apache kann nicht mehr zu den FastCGI Prozessen "connecten".

[deeluxe]

Hey Kase!

Also ich habe einen php-fcgi Prozess, der immer eine minimal 50% bis maximal 100% Cpu Auslastung macht. Es ist immer der gleiche fcgi Prozess!

Edit: Diese Auslastung ist konstant und hört nie auf....

Haste da ne Ahnung, warum das genau immer der gleiche Prozess ist, der diese Auslastung fabriziert?

mfg Tobi

[kase]

Nein, kann ich dir leider nicht sagen. Einzigste Möglichkeit da was rauszufinden, ist wohl ein "strace" auf den Prozess. Das ganze ist aber vermutlich ein Amok laufendes PHP-Script.

[Anonymous]

kann sein des ich es vllt überlesen habe aber ist es möglich auch virtuelle benutzer für diese konfig zu nutzen?

Code: Select all

# pstree -u
init---apache2---apache2(www-data)---php-fcgi(#2000)---20*[php-fcgi]
     ¦         ¦                   +-php-fcgi(#2001)---4*[php-fcgi]
     ¦         ¦                   +-php4-fcgi(#2002)---4*[php4-fcgi]
     ¦         ¦                   +-php-fcgi(#2003)---2*[php-fcgi]
     ¦         ¦                   +-php4-fcgi(#2004)---4*[php4-fcgi]
     ¦         ¦                   +-php4-fcgi(#2005)---2*[php4-fcgi]
     ¦         ¦                   +-php-fcgi-mysqli(#2006)---6*[php-fcgi-mysqli]
     ¦         +-2*[apache2(www-data)]

somit wären keine wirklichen benutzer mehr vorhanden, die sich anmelden können. das würde doch ein weiteres sicherheitsloch vermeiden oder sehe ich des falsch? wenn ja wäre ich für ne schritt für schritt anleitung sehr dankbar ;)

[kase]

Das ganze ist teilweise möglich. Dazu muss suexec natürlich sehr stark gepatched und dann auch selbstgebaut werden. Ich habe da irgendwo mal eine Anleitung gesehen, weiß die Seite aber nicht mehr auswendig. Am besten du suchst mal in google nach suexec und virtuelle user.

[mausgreck]

Hallo, zuerstmal danke für das tolle Howto, hat mich einige Nerven gespart.

Hat eigentlich alles so funktioniert, wie es soll. Statt FastCGI zu compilieren habe ich ohne Probleme das Debian Package verwendet.

Einige Skripts hatten ein Problem, da bei (f)cgi-PHP SCRIPT_NAME anders gesetzt wird. Abhilfe: in php.ini cgi.fixpathinfo=1 setzen.

Ein anderes Skript hat zu spinnen angefangen, da der "Status:"-Header nicht gesetzt werden darf. Abhilfe: die entsprechende Zeile im Skript löschen.

Zum Thema PHP_FCGI_CHILDREN: ich habe kurz den Code überflogen, und für mich sieht es genau umgekehrt aus: Wenn man PHP_FCGI_CHILDREN nicht oder auf 0 setzt, dann wird *nicht* der PHP-Prozessmanager verwendet, sondern das FastCGI-Prozessmanagement. Eigentlich gibt es gar keinen PHP-Prozessmanager: Das CGI startet einfach PHP_FCGI_CHILDREN Prozesse und das wars. Es werden nie neue gestartet. Die einzelnen Prozesse sterben dann nach PHP_FCGI_MAX_REQUESTS Anfragen.

Was das jetzt für die Optimale konfiguration bedeutet, ist mir nicht ganz klar. Ich denke mal, wenn man PHP_FCGI_CHILDREN auf >0 setzt, sollte man auf jeden Fall -minProcesses auf 0 setzen. Und -startDelay nicht zu klein, denn wenn das Spawnen der PHP_FCGI_CHILDREN Prozesse länger als -startDelay dauert kommt es logischerweise zu Massenforks. Wahrscheinlich sollte -maxClassProcesses entsprechend klein gehalten werden, da ja max. -maxClassProcesses * PHP_FCGI_CHILDREN Prozesse gestartet werden.

[tonitone]

feines tutorial ;)

läuft sauber, aber eine frage hätt ich.

was muss ich ändern, wenn ich pear nutzen will!

also wenn ich, egal welcher user,

Code: Select all

pear upgrade-all

z.B. eingebe gibt es eine

Code: Select all

Warning: mkdir(): SAFE MODE Restriction in effect.  The script whose uid is 1004 is not allowed to access /tmp owned by uid 0 in System.php on line 249

fehlermeldung

kann mir jemand dazu einen tip geben?

gruß
toni

[kase]

In deiner php.ini mal kurzzeitig den Safe-Mode abschalten, dann den Befehl ausführen und dann gleich wieder den Safe-Mode aktivieren.

Ã?brigens Danke @mausgreck für deine gute Bewertung/Kritik.