Aus 2 Apachen einen machen... hmmm

[sledge0303]

Hallo Leute,

ich bin erst seit 2 Monaten mit einem Debianserver Sarge 3.1 beschäftigt, hatte vorher mit Linux nicht allzu viel am Hut - zumindest nicht aus servertechnischer Sicht.

Mein momentaner Stand ist dieser:

einen Apache2.0.54 aus Debianpaket(Port80) + FastCGI + PHP 4/5 als CGI (Skripte können parallel ohne Ã?nderungen der Dateinamen im jeweiligen Webverzeichnis mit 4 oder 5 gestartet) + MySQL aus Debianpaketen.

dazu kommt ein zweiter,selbst gebauter, Apache 2.0.54 (Port 40000) mit OpenXchange 0.8.1-2 Groupwareserver, PostgreSQL, Tomcat 5.0.28, Java... und dem jakarta-tomcat-connector-1.2.14.1 (jk2_mod).

Es geht mir darum, der Group- und Webserver sollen auf einen einzelnen Apache laufen und nun geht das Theater aus meiner Sicht los.
Ich schaffe es einfach nicht, in dem Apachen aus der Debianinstallation das Jk2_mod einzubinden. Es funktioniert aber komischerweise bei dem selbst gebauten Apachen in seinem Tipie.
Dort wiederum schaffe ich es nicht FastCGI einzubinden.... grrr

Meine Frage an die erfahrenen Roots:
Sind PHP CGIes ohne FastCGI-Modul geschwindigkeitsmäßig extrem benachteiligt oder hält es sich in Grenzen?

Hoffe meine Anfängerfrage ist nicht zu blöd gestellt, ich denke mir mal das bei der Umsetzung meines Vorhabens ein logischer Fehler meinerseits vorliegt.
Hier in der Firma kann ich keinen Fragen, die haben von der Technik keine Ahnung und sind froh das ich überhaupt so weit in der kurzen Zeit gekommen bin (gerade wegen dem parallelen PHP 4/5 Betrieb)

Gruß

S.

[projekt2501]

Hi,

ja, sie sind benachteiligt. Es kommt aber drauf an, ob es für dich von Relevanz ist. Soll heißen wenn der Server eh nicht immer am Limit läuft und noch Ressourcen zur Verfügung stehen ist es jetzt nicht so wahnsinnig schlimm. (meine persönliche Meinung)

Ich habe auch mal das Problem mit fastcgi gehabt, bin danach su_exec mit PHP als CGI umgestiegen. Das hat für mich super funktioniert und war auch geeignet schnell. Hat sich zumindest nie jemand beschwert, dass Seiten langsam gewesen wären.

Schau mal in unten stehende Seite rein. Da unter Benchmarks findest du nen guten Hinweis wie sich FAST-CGI auswirken kann. Hab selbst auch mal nen Stresstest gemacht mit 1000 gleichzeitigen Nutzern, ich habe praktisch nie über 8-10 Instanzen von PHP gehabt (jede Instanz so um die 6 MB). Was ich getestet hatte war einfach der aufruf von phpinfo();

http://phplens.com/phpeverywhere/fastcgi-php

Bitten nicht gleich steinigen, aber der Artikel bezieht sich auf den IIS :)

Schönen Gruß
Projekt2501

[sledge0303]

Danke für die Antwort, ist schon ein deutlicher Unterschied zwischen beiden zu erkennen. Unsere Leute müssen sehr viel mit Grafik arbeiten, d.h. die Funktionen mit dem "gd" werden sehr ausgereizt. Schätze mal das die Damen und Herren Softwareentwickler nicht so lange warten wollen.
Ich finde es nur umständlich mit 2 Apachen unter einem Dach, werde wohl weiter selbst experimentieren müssen zu Hause auf meinem Testserver - um zumindest auf dem selbstgebauten Apachen FastCGI zum laufen zu kriegen.
Hab alles andere auch soweit hinbekommen und hoffe immer noch das mir einer den entscheidenen Hinweis mit dem Jk2 geben kann.
Ich hab noch eine andere Option, indem die Installation eines Apache 1.3 zusammen mit openxchange beschrieben wird. Die Werte entsprechend dem 2.0er anpassen und danach KÃ?NNTE es gehen.

Linux ist eine Gewöhnugssache, muss aber zugeben, einmal am Debian gesessen und will nichts anderes mehr administrieren :D

S.

[Roger Wilco]

Was klappt denn genau nicht mit mod_jk2?
Fehlermeldungen, Logs, Configs?

[sledge0303]

Hallo Roger,

ich habe jk2_mod über den apt installiert. Das Modul von mods available in enabled gelinkt mit ln -s...
In der httpd.conf habe ich folgende Befehle eingetragen:

Code: Select all

LoadModule jk2_module /etc/mods-enabled/mod_jk2.so

Im default VHOST folgenden Eintrag vorgenommen:

Code: Select all

...
#
<IfModule mod_jk2.c>
JkWorkersFile /etc/apache2/workers.properties
JkLogFile /etc/apache2/logs/mod_jk.log
JkLogLevel warn
JkMount /*.jsp localhost
JkMount /servlet/* localhost
JkMount /umin/* localhost
JkMount /examples/* localhost
JkMount /servlet/webdav.contacts* localhost
</IfModule>

workers.properties sieht so aus:

Code: Select all

worker.list=localhost
worker.localhost.port=8009
worker.localhost.host=localhost
worker.localhost.type=ajp13
worker.localhost.lbfactor=1
workers.tomcat_home=/usr/local/tomcat
workers.java_home=/usr/local/java

Die Pfade zum Java und Tomcat stimmen überein. Was aber noch sein kann ist, in dem selbstgebauten Apachen habe ich ein jk_mod (ohne die 2 dazwischen) eingebaut. Hervorgehend aus dem tomcat-connector-1.14. Für den selbstgebauten Apachen habe ich das jk_mod so in sein Tipie gebaut:

Code: Select all

tar -zxf jakarta-tomcat-connectors-1.2.14.1-src.tar.gz
cd jakarta-tomcat-connectors-1.2.14.1-src/jk/native
./configure --with-apxs=/usr/local/apache2/bin/apxs
make
make install

Dieses configure habe ich entsprechend geändert in

tar -zxf jakarta-tomcat-connectors-1.2.14.1-src.tar.gz
cd jakarta-tomcat-connectors-1.2.14.1-src/jk/native
./configure --with-apxs=/etc/apache2/bin/apxs
make
make install

Beschwerden über fehlende Pakte, gerade im Zusammenhang mit APXS habe ich während der Kompilierung nicht zu sehen bekommen.

Der Fehler macht sich so bemerkbar, wenn ich versuche mich über die Webschnittstelle in das OX einzuloggen, eine PostgreSQL Datenbank besteht bereits, verschwindet der Anmeldebildschirm und der Bildschirm bleibt leer - ohne Fehlermeldung. Selbst das logfile ist blütenweiß... grummel...
Meines erachtens nach wurden alle Pfade entsprechend dem Make usw angepasst an den Paket-Apachen (was für ein Wort, fällt aber nichts besseres ein ;)).
Will aber nicht ausschließen woanders einen logischen Fehler verursacht zu haben.
Ich weiß nur noch nicht wo noch nach dem Fehler gesucht werden kann.

EDIT
So habe ich die beiden Apachen installiert bzw. Kompiliert:

Apache2.0.54 Debianpaket:

Code: Select all

apt-get install apache2-common apache2-mpm-worker apache2-threaded-dev

selbstgebauter:

Code: Select all

./configure --prefix=/usr/local/apache2 --with-mpm=prefork --enable-rewrite --enable-deflate --enable-vhost-alias --enable-so

Liegt zwischen beiden etwas was ich evtl. nicht beachtet haben könnte?
/EDIT

[sledge0303]

Hallo Roger,

bin gerade zu Hause an meinem Testserver angekommen. Hier ist das Ergebnis, FastCGI auf meinem selbstgebauten Apachen laufen zu lassen incl. der Fehlermeldung:

httpd.conf

Code: Select all

...
LoadModule jk_module modules/mod_jk.so
LoadModule fastcgi_module modules/mod_fastcgi.so
LoadModule suexec_module modules/mod_suexec.so
...
#AddHandler cgi-script .cgi
FastCgiWrapper /usr/lib/apache2/suexec2
FastCgiServer /var/www/php-fcgi-scripts/ml-company/php-fcgi-starter -user admin -group admin
 
AddHandler php-fastcgi .php
 
<Location /cgi-bin/php-fcgi-starter>
        SetHandler fastcgi-script
        Options +ExecCGI
</Location>
 
Action php-fastcgi /cgi-bin/php-fcgi-starter
 
AddType application/x-httpd-php .php

Wenn ich den Apachen neu starten möchte, erscheint diese Fehlermeldung:

Code: Select all

FastCgiWrapper: "/usr/lib/apache2/suexec2" execute access for server (uid 65534, gid -1) failed: execute not allowed

Unter dem Apachen aus dem Debianpaket läuft alles prima.
Kann es sein das der suexec neu kompiliert oder evtl. eine neue Rechtevergabe für suexec erfolgen muss?
Die Meldung erscheint auch, wenn root statt admin eingesetzt wird!

S.

[Roger Wilco]

Wie sehen die Permissions für /usr/lib/apache2/suexec2 aus? Unter welchem Benutzer läuft der Apache?

[sledge0303]

Wie sehen die Permissions für /usr/lib/apache2/suexec2 aus? Unter welchem Benutzer läuft der Apache?

Moin,

der Apache läuft als Root und suexec2 habe ich vorerst auf nobody:nogroup gesetzt.
Ich denke mal eher beim bauen des Apachen habe ich folgendes nicht bedacht, --enable-suexec und die Sache beim Apachen mit dem
mpm-worker und dem prefork. Glaube nicht das beides zusammen eingebaut werden kann. Zuerst war auch keine gemeinsame Nutzung PHP4/5, FastCGI, Webserver und OpenXchange auf nur einem Apachen geplant.
OpenXchange und PHP4/5 mit FastCGI benötigen in der Config des Apachen verschiedene CGI-BIN Pfade. Habe mal versucht beide Pfade zu den CGIs zusammen zu legen, d.h. die FCGI Starter und die login.pl / login.pm zusammen in ein Verzeichnis gelinkt. Funktioniert hatte es nicht, leider. War eben nur ein Test.
Will in den nächsten Tagen meinen Windoofs Testrechner platt machen und auf die 2.Partition Debian installieren.
...oder meine Frau erschießt mich vorher wegen der ganzen Tests jeden Abend... :D

[Roger Wilco]

der Apache läuft als Root und suexec2 habe ich vorerst auf nobody:nogroup gesetzt.

Schlechte Idee. Der Apache sollte unter einem eigenen Benutzer laufen (apache, httpd, wwwrun, whatever...) und die suexec2 muß root gehören und das SUID-Bit gesetzt haben, sonst wird das nix mit dem "Su" von SuExec...

Ich denke mal eher beim bauen des Apachen habe ich folgendes nicht bedacht, --enable-suexec und die Sache beim Apachen mit dem
mpm-worker und dem prefork. Glaube nicht das beides zusammen eingebaut werden kann.

Doch, geht. Das eingesetzte MPM ist SuExec egal.

[sledge0303]

Hallo Roger,

erstmal Danke für diese Hinweise. Wie gesagt will ich demnächst auf einem anderen Rechner Debian installieren und den Apachen von Sich aus alleine zusammenbauen - d.h. keine Paketinstallation. Habe aber diesbezüglich noch kleine Fragen.
Bei der Installation des PHP FCGI bin ich ziemlich deiner Anleitung vorgegangen, habe Apache2 mit dem MPM Worker installiert.
Bei der Installation des OpenXchange wird ausdrücklich hingewiesen, es soll mit dem MPM-Prefork gearbeitet werden. Wenn ich dich richtig verstanden habe, kann ich FCGI, suexec und PHP4/PHP5 auch mit dem Prefork betreiben, richtig?
Da OpenXchange als Perlskript ausgeführt wird, muss dafür ein CGI Verzeichnis erstellt werden,Pfad zum CGI-BIN wird beim kompilieren von OX eingesetzt. Kann ich die PHP CGI Starter und die Perl Skripte zusammen in dieses CGI Verzeichnis packen?

Des weiteren hätte ich noch eine Frage, ich dokumentiere bei der folgenden Installation jeden Schritt. Sollte ich es nicht hinbekommen mit meiner Kompilierung/Installation, kann ich dir dann mal meine schrittweise Doku zusenden, evtl. findest du dann ja einen Fehler?

S.