Herausfinden, welches Apache2 MPM ist geladen ist



haschi

Registered User
Hallo!

Kurze Frage. Wie finde ich heraus, welches MPM installiert ist?

Ich bin grad etwas verwirrt, wo ich in den Docs vom Apache2 das hier gelesen habe:
http://httpd.apache.org/docs/2.0/mpm.html#defaults
UNIX-Standard: prefork

Wenn ich jetzt unter Debian per "apt-get install apache2" den Apache installiere, wird mir vorgeschlagen, dass er den worker installiert. Oder gilt obige Aussage nur, wenn ich den Indianer ohne Angabe von Argumenten selber kompiliere?

Gruß
Marco
 
So, wieder bei klarem Kopf. Bin etwas auf dem Schlauch gestanden und bin grad eine Installation auf einem Debian komplett durchgelaufen.

Installiert man Apache nur mit dem Kommando "apt-get install apache2", wird standardmäßig der worker, Installiert man dann danach php5 wird der worker automatisch gegen den prefork "getauscht".

Somit ist meine obige Frage auch wieder hinfällig. Einfach ruhe bewahren und das Gehirn einschalten... :o :)
 
Die generische Antwort lautet übrigens `httpd -V|grep MPM` (ggf. `apache2` statt `httpd`, wenn die Distribution die Binaries so wie Debian umbenennt).
 
-V listet nicht zwingend den aktuell verwendeten MPM, daher ist -M zu bevorzugen:
Code:
httpd -M|grep mpm
 
Danke für eure Antworten!
Hab mal apache2 -M ausprobiert. Dann kommt nur das:
Code:
stats:/# apache2 -M
apache2: bad user name ${APACHE_RUN_USER}

apache2 -V gibt mir dann aber eine ganze Liste an Informationen heraus.

Aber grad mal eine andere Frage, wollte da jetzt nicht unbedingt ein neues Thema für aufmachen.
Wie ist es zu empfehlen den Apache zu installieren? Direkt über die Paketquellen oder als Source und dann kompilieren?
 
Bei einem aktuellen und noch im Supportzeitraum befindlichen Betriebssystem solltest du die offiziellen Paketquellen nutzen.
 
Hab mal apache2 -M ausprobiert. Dann kommt nur das:
Code:
stats:/# apache2 -M
apache2: bad user name ${APACHE_RUN_USER}

Das liegt an den bekloppten Debian-Maintainern, die sich seit über zehn Jahren weigern, sich an die "Standards" zu halten und stattdessen ihr eigenes gefährliches Süppchen kochen... Bei jeder anderen Distribution und jedem anderen OS tritt dieser (und viele andere) Fehler nicht OOTB auf.
 
Okay?! Das 'apache2' eine eigenart von Debian ist, ist mir bekannt. Was genau ist daran jetzt schlecht ds der Dienst nicht 'httpd' heißt?

BTW: Welche Distri ist denn noch zu empfehlen für einen Webserver? Nutze Debian eigentlich schon immer für den Server. Daher kam für mich jetzt nie was andere in Frage.
 
Nicht das Umbenennen des Binary, was andere Distros leider ebenfalls machen, werfe ich den Debian-Maintainern vor, sondern das rücksichtslose Einpatchen von unnötigem und fehlerhaften Code (in diesem Fall für die APACHE_RUN_[USER|GROUP] Variablen, welche zudem sicherheitstechnisch problematisch sind).

Zu empfehlen sind unter Anderem:
FreeBSD, SLES und Gentoo
 
Last edited by a moderator:
Gibt es darüber eine Art Dokumentation, wo das genauer beschrieben wird? Interessiert mich denn doch schon etwas.
 
Gentoo
FreeBSD
SLES

Bzgl. deines "Bad Usernames" schnapp dir die Zeilen aus /etc/apache2/envvars, führ die aus und pack die irgendwo hin, dass die beim booten auch geladen werden - dann tut's auch dein apache2 -M.
 
Sowohl unter Debian als auch unter OpenSUSE empfiehlt sich nicht die direkte Nutzung des Daemons-Binaries.
Als Alternative ist jeweils ein Wrapper beigelegt: apache2ctl

huschi.
 
Sowohl unter Debian als auch unter OpenSUSE empfiehlt sich nicht die direkte Nutzung des Daemons-Binaries.
Als Alternative ist jeweils ein Wrapper beigelegt: apache2ctl
Der Wrapper gehört zum Apache selbst und ist nicht distributionsspezifisch.

Alternativ ist apache2 -l auch ein Weg um den MPM herauszufinden.
Falsch, denn das Runtime-MPM muss nicht mit dem Compiletime-MPM übereinstimmen und wir benötigen hier nunmal das Runtime-MPM.
 
Last edited by a moderator:
... sondern das rücksichtslose Einpatchen von unnötigem und fehlerhaften Code (in diesem Fall für die APACHE_RUN_[USER|GROUP] Variablen, welche zudem sicherheitstechnisch problematisch sind).

Ich meinte eher dazu eine Art Dokumentation.
 
Was möchtest Du da dokumentiert haben? Die Patches? Dazu wirst Du die entsprechenden Mailinglisten bei Debian durchsuchen und/oder die Patches analysieren müssen. Dazu habe ich weder Zeit noch Lust, zumal ich Debian und seine Derivate grundsätzlich nicht auf produktive Systeme loslasse.
 
Back
Top