apache2.0.50 + PHP 5.0.0 sinnvoll konfigurieren

[XaraX]

Guten Morgen,

OS:        SuSE Linux
Server:    Apache 2.0.50
Modul:     PHP 5.0.0

heute hatte ich mir einen server kompiliert mit folgenden modulen

core.c
  mod_access.c
  mod_auth.c
  mod_log_config.c
  mod_logio.c
  mod_mime_magic.c
  mod_headers.c
  prefork.c
  http_core.c
  mod_mime.c
  mod_status.c
  mod_asis.c
  mod_dir.c
  mod_actions.c
  mod_userdir.c
  mod_alias.c
  mod_so.c

Da der Rechern schon etwas altersschwach ist, will ich den Server so schlank wie möglich halten. Er ist sogar nur dazu da, mir eine Entwicklungsumgebung für PHP bereitzustellen. Mit PHP will ich auch im Netzwerk arbeiten (Netzwerkfunktionen nutzen).

Welche Module kann beim nächsten Durchlauf entsorgen?
Welche Module habe ich möglicherweise vergessen?
Macht es mehr Sinn PHP fest einzukomilieren?

Vielen Dank Gruß aus Berlin!
eddi

[Severin Kacianka]

Hallo,

Welche Module kann beim nächsten Durchlauf entsorgen?
Welche Module habe ich möglicherweise vergessen?
Macht es mehr Sinn PHP fest einzukomilieren?

Also wenn der Server nur zur PHP-Entwicklung dienen soll, reicht es wenn du ihn mit --enable-so kompilierst. Du kannst, soweit mir bekann, PHP nicht direkt in Apache 2.x.x einkompilieren. Wenn der Server sehr langsam ist, kannst du eventuell mehr erreichen, wenn du schaust, dass so wenig Programme wie möglich neben dem Apachen laufen.

Gruß,
Severin

[XaraX]

Hallo Severin,

danke für Deinen Tip. Das werde ich morgen mal ausprobieren.

Gruß aus Berlin!
eddi

[XaraX]

Hallo!

danke für Deinen Tip. Das werde ich morgen mal ausprobieren.

Dieser Beitrag könnte auch die Überschrift "MIME-Type Problem" haben. Daher noch ein paar gesammelte Erkenntnisse, die vielleicht auf Konfigurationsfehlern von mir beruhen können.

Der Apache verweigert leider seinen Dienst PHP als Handler einzubeziehen, wenn er nur die vier Standardmodule hat:

schmuckstueck:~ # httpd -l
   core.c
   prefork.c
   http_core.c
   mod_so.c

(wobei PHP als LoadModule angegeben wurde)

Ob das nun an SuSE lieg, vermag ich nicht zu beurteilen. Erst wenn mime_module (ebenfalls LoadModule) einbezogen wird, läuft PHP.

Eine weitere Eigenheit hat mich auch seit Beginn des Zusammenstellens der httpd.conf begleitet.
Notiert man "Option -Indexes" in der Serverkonfiguration, wird man an HTML-Dateien keine freude haben. Der Server serviert sie befließen mit dem MIME-Type text/plain ([Voreinstellung des "DefaultType"] auch bei "DefaultType text/html"). Weder die Integration von mime_module, noch von mime_magic_module und deren Konfigurationsanweisungen ändern an diesem Zustand irgendetwas.

Soweit mein jetziger Erkenntnisstand. Vielleicht kann dies im Archiv jemanden vor der gleichen zeitraubenden Fehlersuche bewahren.

Gruß aus Berlin!
eddi

[Andreas Korthaus]

Hallo!

Dieser Beitrag könnte auch die Überschrift "MIME-Type Problem" haben. Daher noch ein paar gesammelte Erkenntnisse, die vielleicht auf Konfigurationsfehlern von mir beruhen können.

Der Apache verweigert leider seinen Dienst PHP als Handler einzubeziehen, wenn er nur die vier Standardmodule hat:

Natürlich, nicht weil AddHandler in keinem der von Dir verwendeten Module vorhanden ist. Siehe: http://httpd.apache.org/docs-2.0/mod/mod_mime.html#addhandler

schmuckstueck:~

netter Name ;-)

httpd -l

core.c
   prefork.c
   http_core.c
   mod_so.c

Da wird Dir noch ne Menge fehlen, es sei denn Du lädst den Rest dynamisch (die werden da nämlich nicht gelistet).
So Sachen wie Basic-Authentication, oder dass bei einem Request GET / nach GET /index.htm umgeleitet wird, oder "deny from all"... dazu gibt es extra Module.

(wobei PHP als LoadModule angegeben wurde)

Das reicht nicht.

Notiert man "Option -Indexes" in der Serverkonfiguration, wird man an HTML-Dateien keine freude haben. Der Server serviert sie befließen mit dem MIME-Type text/plain ([Voreinstellung des "DefaultType"] auch bei "DefaultType text/html"). Weder die Integration von mime_module, noch von mime_magic_module und deren Konfigurationsanweisungen ändern an diesem Zustand irgendetwas.

Da bezweifele ich dass "Option -Indexes" was damit zu tun hat, das sorgt nur dafür, dass wenn keine index-Datei vorhanden ist der Verzeichnisinhalt nicht gelistet wird. Wozu aber sowieso mod_autoindex notwendig wäre.
http://httpd.apache.org/docs-2.0/mod/core.html#options

In meiner httpd.conf steht sowas:

<IfModule mod_mime.c>
    TypesConfig conf/mime.types
</IfModule>

Also

cat mime.types | grep "text/html"

text/html                       html htm

Ich denke irgendwas wird bei Dir fehlen. Entweder komplett mod_mime, oder die TypesConfig Direktive, oder die angegebene Datei wird nicht gefunden.

Grüße
Andreas

[Christoph Schnauß]

hallo Eddi,

OS:        SuSE Linux
Server:    Apache 2.0.50
Modul:     PHP 5.0.0

Ich weiß nicht, woran es liegt, daß ich auf den SuSE-Servern noch kein RPM für PHP5 finden kann, die anderen "großen" Distributionen stellen ihre Packages längst bereit.

Zu deiner Liste: einige der aufgeführten Module sind "core"-Module, die du nicht entsorgen kannst. "core", "so" und "http_core" sind immer fest einkompiliert, "prefork" ist das MPM-Modul. Die vier wirst du auf gar keinen Fall los, kannst dir aber ein anderes MPM-Modul auskucken. Bei allen anderen kannst du überlegen, ob du die Funktionen brauchst, für die sie zuständig sind. Eine schnelle Übersicht findest du in der Vorabversion meines Apache-Artikels unter http://temp.christoph-schnauss.de/apacheconf/apconf08.htm#a2. "mod_logio" ist zum Beispiel nicht immer notwendig, und für deine Zwecke wirst du auch auf "mod_userdir" verzichten können.

Macht es mehr Sinn PHP fest einzukomilieren?

Nein. Es ist sogar schwierig, das überhaupt einzukompilieren, dazu müßtest du ziemlich tief in die Apache-Sourcen eingreifen.

Grüße aus Berlin

Christoph S.

[XaraX]

Hallo Christoph,

Ich weiß nicht, woran es liegt, daß ich auf den SuSE-Servern noch kein RPM für PHP5 finden kann, die anderen "großen" Distributionen stellen ihre Packages längst bereit.

Ohne Worte :\ (Achje [seufts] - wenn ich doch mit mehr umgehen könnte als nur mit SuSE [traurig_auf_die_Debian_CDs_schauend])

... "prefork" ist das MPM-Modul. [...] kannst dir aber ein anderes MPM-Modul auskucken.

Direkte Anschlußfrage: SuSE startet den von Hause aus mitgelieferten Server über http2-prefork, auch rät mir eine geheime Quelle zu prefork, daher habe ich mich für dies entschieden. Wo aber ist der Unterschied zwischen beos|worker|prefork|mpmt_os2|perchild|leader|threadpool?

... http://temp.christoph-schnauss.de/apacheconf/apconf08.htm#a2.

Ups ;) da ist sie ja meine geheime Quelle.
Nochmal vielen Dank noch mal für diese gute Starthilfe!

Gruß aus Berlin!
eddi

[Christoph Schnauß]

hallo Eddi,

Wo aber ist der Unterschied zwischen beos|worker|prefork|mpmt_os2|perchild|leader|threadpool?

Hier ist die Quelle dazu: http://httpd.apache.org/docs-2.0/mod

Grüße aus Berlin

Christoph S.

[XaraX]

Hallo Christoph, hallo Andreas,

danke Euch beiden.
Demnach ist prefork gegen worker die beste Wahl für mich, da PHP als nicht threadsave beschrieben wird - läßt sich dies so auf den Punkt bringen, oder habe ich dort etwas falsch verstanden?

Gruß aus Berlin!
eddi

[Andreas Korthaus]

Hallo!

Demnach ist prefork gegen worker die beste Wahl für mich, da PHP als nicht threadsave beschrieben wird - läßt sich dies so auf den Punkt bringen, oder habe ich dort etwas falsch verstanden?

PHP selbst ist schon threadsafe (zumindest ist man sich da relativ sicher), aber die vielen 3rd-party Libs wie z.B. postgresql, gd... da sind einige von definitiv nicht threadsafe, von anderen wiederum weiß man es nicht sicher...

Ich denke das folgende Posting auf php.internals sollte Deine Zweifel ausräumen, ich denke der Autor ist da durchaus kompetent ;-)

http://news.php.net/php.internals/10491

Siehe auch: http://httpd.apache.org/docs-2.0/developer/thread_safety.html#liblist, ist zwar etwas veraltet, verdeutlich aber das Problem.

Grüße
Andreas

[XaraX]

Hallo Andreas,

danke - das war sehr aufschlußreich, aber, da ich um Datenbanken, wo ich nur kann, einen Bogen mache, adererseits auch kaum mit --with-[res] (bz2 & curlwrappers schon noch) arbeiteen möchte, stellt sich nun mein Grundproblem ein:

Default für Unix ist prefork.
                    Worker wäre auch wählbar.

In http://httpd.apache.org/docs-2.0/new_features_2_0.html und ../mod/ werden die einzelnen Erweiterungen beschrieben. Letzentlich entnehme ich den Beschreibungen -wenn apache2, dann mit MPM, sonst macht es keinen Sinn 2.x überhaupt zu verwenden-.

Ich gebe zu, es ist nur eine theoretische Überlegung. Es werden in meinem home.net keine 300 Anfragen pro Sekunde anfallen, die dann auch noch mit PHP bedient werden. Also werde ich es mal mit worker versuchen.

Interessieren würde es micht doch, welche Variante auf einem produktivem System (wovon noch abgeraten wird) bevorzugt einzusetzen ist.

Gruß aus Berlin!
eddi

[Andreas Korthaus]

Hi Eddi!

danke - das war sehr aufschlußreich, aber, da ich um Datenbanken, wo ich nur kann, einen Bogen mache,

Wieso? Kommt halt auf die Anwendung an, aber ich mache online eigentlich fast nichts ohne DB ;-)

adererseits auch kaum mit --with-[res] (bz2 & curlwrappers schon noch) arbeiteen möchte, stellt sich nun mein Grundproblem ein:

Default für Unix ist prefork.
                    Worker wäre auch wählbar.

In http://httpd.apache.org/docs-2.0/new_features_2_0.html und ../mod/ werden die einzelnen Erweiterungen beschrieben. Letzentlich entnehme ich den Beschreibungen -wenn apache2, dann mit MPM, sonst macht es keinen Sinn 2.x überhaupt zu verwenden-.

MPM heißt "Multi-Processing Module", und ohne sowas funktioniert kein Apache2. Du kannst Dir halt das Modul auswählen, es gibt Module für spezielle Architekturen optimiert, wie z.B. Win32, und für Unix stehen eigentlich vor allem prefork und worker zur Auswahl, die anderen sien AFAIK noch nicht stabil. Per default wird auf Unix prefork-MPM verwendet, dieses entspricht in der Funktionsweise dem Apache 1.3, man kann alternativ das worker-MPM verwenden, welches ebenfalls mehrere Prozesse verwendet, allerdings auch mehrere Threads pro Prozess. Das ist bei statischen Inhalten kein Problem, daher würde ich in dem Fall durchaus dieses MPM wählen. Bei dynamischen Inhalten muss sichergestellt sein, dass sämtliche verwendeten Bibliotheken threadsafe sind, da es sonst zu diesen seltsamen Fehlern kommt.

Du kannst mit ldd nachsehen welche Bibliotheken Dein mod_php.so verwendet, siehe http://httpd.apache.org/docs-2.0/developer/thread_safety.html#commonlibs

Jetzt musst Du für jede der verwendeten Bibliothek sicher sein, dass sie Threadsafe ist.

PostgreSQL war nur ein Beispiel, das hat nicht prinzipiell was mit Datenbanken zu tun, das kann jede Bibliothek sein.

Jedenfalls stimmt für mich hier nicht das Verhältnis von Kosten/Risiko zum Nutzen, denn es wird sich auch kaum bemerkbar machen - es ist nicht so dass der Apache dann auf einmal doppelt so schnell PHP-Scripte ausliefert, und scon gar nicht mit der Thread-Implementierung des 2.4er Linux Kernels.

Ich sehe es allerdings nicht so hart mit Apache_2.0-prefork vs. Apache 1.3.
Natürlich, Apache 1.3 und mod_php haben sich Millionenfach bewährt, und laufen wirklich sehr stabil zusammen. Auf der anderen Seite, der Apache 2 wurde ja nicht zum Spaß entwickelt, sindern ist eine Weiterentwicklung, eine Verbesserung mit den Erfahrungen aus 1.3.

Wenn ich mir mal die Zeitpunkte der alten Releases ansehe: http://archive.apache.org/dist/httpd/old/

1. Alpha  03/2000
1. Beta   11/2001
1. Stable 04/2002

Das heißt da stecken jetzt weit über 4 Jahre Entwicklung drin, das Entwickler-Team ist so groß wie nie, seit über 2 Jahren gibt es eine stabile Version, und wenn ich das grob richtig abschätze:

http://www.securityspace.com/s_survey/data/200407/servers.html

wird Apache2 inzwischen auf über 1 Mio Webservern produktiv eingesetzt.

Das heißt, ich würde bei einer neuen Installation inzwischen auf Apache2 setzen, für statische Inhalte mit Worker-MPM, für dynamische mit Prefork-MPM.

Ich gebe zu, es ist nur eine theoretische Überlegung. Es werden in meinem home.net keine 300 Anfragen pro Sekunde anfallen, die dann auch noch mit PHP bedient werden. Also werde ich es mal mit worker versuchen.

Ich würde versuchen lokal möglichst ähnliche Software/Konfigurationen zu verwenden, wie auf dem produktiven System. Für Deine Ansprüche ist das relativ egal, da kann vermutlich die Thread-unsicherste Bibliothek verwendet werden, und es würde sicher nichts passieren. Würdest Du die selbe Konfiguration auf einem großen produktiven System verwenden, sieht die Sache auf einmal ganz anders aus. Ich würde defintiv Prefork empfehlen.

Interessieren würde es micht doch, welche Variante auf einem produktivem System (wovon noch abgeraten wird) bevorzugt einzusetzen ist.

Bei besonders kritischen Sachen vielleicht noch Apache 1.3, aber prinzipiell würde ich inzwischen immer Apache 2.0 mit Pefork-MPM verwenden. Und wie gesagt würde ich Test- und produktiv-System so ähnlich wie möglich konfigurieren. Gerade bei Thread-Problemen bringt Dir das herzlich wenig das erstmal auf dem Testsystem auszuprobieren, da die Fehler erst unter Last, also später im Live-Betrieb auftreten.

Grüße
Andreas

[XaraX]

Vielen Dank!

danke - das war sehr aufschlußreich, aber, da ich um Datenbanken, wo ich nur kann, einen Bogen mache,
Wieso? Kommt halt auf die Anwendung an, aber ich mache online eigentlich fast nichts ohne DB ;-)

Da habe ich grade beim bauen von O-Shops eine heiden Angst, daß mir Daten ohne Abschietsbrief in den Urlaub fahren, oder Stato-like die DB abschmiert und ich dann ein zimliches Probelm bekomme.
Bei anderen Webs bin ich kein wirklicher Freund von Geschichten wie

show.php?zeig=mal_hier&mach=mal_da

obwohl, wenn Gründe dafür sprechen sollten, ist das auch noch mit mir machbar. Definitive Grenze des mir verständlichen sind aber image-DB.

[...]

Danke für die erschöpfenden Auskünfte :)

Gruß aus Berlin!
eddi

[Andreas Korthaus]

Hi!

Wo aber ist der Unterschied zwischen beos|worker|prefork|mpmt_os2|perchild|leader|threadpool?

siehe: http://httpd.apache.org/docs-2.0/mpm.html

Grüße
Andreas

[XaraX]

Hallo,

besteht die Möglichkeit innerhalb der config.layout eine eigene Variabel zu definieren? Ich dachte mir dies so:

<Layout Mein_Layout>

meine-variable:     irgendwas
apache-variable:    /verzeichnis/{meine-variable}
</Layout>

Gruß aus Berlin!
eddi

[Andreas Korthaus]

Hallo!

besteht die Möglichkeit innerhalb der config.layout eine eigene Variabel zu definieren? Ich dachte mir dies so:

<Layout Mein_Layout>

meine-variable:     irgendwas
apache-variable:    /verzeichnis/{meine-variable}
</Layout>

Hm, ich glaube so einfach geht das leider nicht.

Für bestimmte Zwecke (dynamische vhosts) kann mod_vhost_alias helfen: http://httpd.apache.org/docs-2.0/mod/mod_vhost_alias.html
http://httpd.apache.org/docs-2.0/vhosts/mass.html

und sonst vielleicht mod_rewrite:
http://httpd.apache.org/docs-2.0/vhosts/mass.html#simple.rewrite
http://httpd.apache.org/docs-2.0/mod/mod_rewrite.html
http://httpd.apache.org/docs-2.0/misc/rewriteguide.html

Evtl. könnten auch Umgebungsvariablen helfen: http://httpd.apache.org/docs-2.0/env.html
http://httpd.apache.org/docs-2.0/mod/mod_env.html#setenv
http://httpd.apache.org/docs-2.0/mod/mod_setenvif.html#setenvif

Grüße
Andreas

[XaraX]

Hallo!

besteht die Möglichkeit innerhalb der config.layout eine eigene Variabel zu definieren? Ich dachte mir dies so:

<Layout Mein_Layout>

meine-variable:     irgendwas
apache-variable:    /verzeichnis/{meine-variable}
</Layout>

Ich glaube es liegt ein Verständnisproblem zugrunde. die config.layout wird für configure/make/make install als Schema herangezogen daher helfen mir definierbare Variablen von Modulen, die erst nach der Erstellung und dem Start zur Verfügung stehen wenig.

Hintergrund der Frage ist, daß ich ein festes Schema gefunden habe, um Ordung zwischen den einzelen Versuchsservern zu habe, welches mit --prefix=/usr/local/${versuchsID} arbeitet. Da beispielsweise /logs als /usr/local/${versuchsID}/anderes_verz/logs angelegt werden soll, baut es auf eine potenziell selbstzudefinierenden Variablen auf. Nur bin ich mir nicht sicher, ab mir das make nicht um die Ohren haut.

Leider braucht ein Durchlauf von configure oder make auf dieser alten Mühle sehr lange. Daher wollte ich erst fragen, bevor ich das mal ausprobiere :}

Gruß aus Berlin!
eddi

[XaraX]

Guten Morgen,

bei der Konfiguration des Apachen bin ich auf <IfDefine></IfDefine> gestoßen. Per <IfDefine>Include</IfDefine> möchte ich verschiedene Schemata laden können. Wenn der Server ohne Parameter aufgerufen wird (# httpd -k start), könnte ich einen Standardkonfiguration auserhalb von <IfDefine>-Direktiven definieren, die aber u. U. ein Schema kompromitieren.

Gibt es eine Möglichkeit dem Server ein Schema zuzuweisen, wenn er ohne Parameter aufgerufen wurde, oder bleibt mir dann nur die Option -f [/verzeichnis/ersatz.conf]?

Gruß aus Berlin!
eddi

[Andreas Korthaus]

Hi!

Gibt es eine Möglichkeit dem Server ein Schema zuzuweisen, wenn er ohne Parameter aufgerufen wurde, oder bleibt mir dann nur die Option -f [/verzeichnis/ersatz.conf]?

Das geht soweit ich weiß nicht. Aber Du solltest durch geschickte Verwendung von <IfDefine VAR>,  <IfDefine !VAR>, <IfModule mod_beispiel.c>, <IfModule !mod_beispiel.c> und include, eine ganze Menge abbilden können.

Bei Gentoo Linux wird das so gemacht, dass es eine allgemeine Apache-config gibt, die für alle Konfigurationen gilt, die dann immer in eine spezielle config-Datei eingebunden wird. Du musst ja nicht die verwendete config-Datei manuell bei jedem Start angeben, Du kannst ja auch ein 2., entsprechend angepasstes Startscript in /etc/init.d legen.

Grüße
Andreas

[XaraX]

Hallo!

Gibt es eine Möglichkeit dem Server ein Schema zuzuweisen, wenn er ohne Parameter aufgerufen wurde, oder bleibt mir dann nur die Option -f [/verzeichnis/ersatz.conf]?
Das geht soweit ich weiß nicht. Aber Du solltest durch geschickte Verwendung von <IfDefine VAR>,  <IfDefine !VAR>, <IfModule mod_beispiel.c>, <IfModule !mod_beispiel.c> und include, eine ganze Menge abbilden können.

Machmal ist es einfacher als man denken mag. Nach 1 h intensivem Ausprobierns bin ich dann auf die einfachste und logischste Möglichkeit gestoßen:

<IfDefine schema1></IfDefine>
<IfDefine schema2></IfDefine>
<IfDefine schema3></IfDefine>
<IfDefine schema4></IfDefine>
<IfDefine schema5></IfDefine>

<IfDefine !schema1>
 <IfDefine !schema2>
  <IfDefine !schema3>
   <IfDefine !schema4>
    <IfDefine !schema5>
          # Standard_schema
    </IfDefine>
   </IfDefine>
  </IfDefine>
 </IfDefine>
</IfDefine>

Nirgends, weder in der Documentation apaches, noch in der Fachliteratur (<./archiv/> ;) steht beschrieben, daß sich diese Anweisungen verschachteln lassen >:\

Bei Gentoo Linux wird das so gemacht, dass es eine allgemeine Apache-config gibt, die für alle Konfigurationen gilt, die dann immer in eine spezielle config-Datei eingebunden wird. Du musst ja nicht die verwendete config-Datei manuell bei jedem Start angeben, Du kannst ja auch ein 2., entsprechend angepasstes Startscript in /etc/init.d legen.

Die Möglichkeit hört sich auch gut an! Das werde ich mal ausprobieren. Nachmals herzlichen Dank für Deine Hilfsbereitschaft :)))

Gruß aus Berlin!
eddi

[Andreas Korthaus]

Hi!

<IfDefine schema1></IfDefine>
<IfDefine schema2></IfDefine>
<IfDefine schema3></IfDefine>
<IfDefine schema4></IfDefine>
<IfDefine schema5></IfDefine>

<IfDefine !schema1>
<IfDefine !schema2>
  <IfDefine !schema3>
   <IfDefine !schema4>
    <IfDefine !schema5>
          # Standard_schema
    </IfDefine>
   </IfDefine>
  </IfDefine>
</IfDefine>
</IfDefine>

Also sowas würde ich persönlich nicht machen ;-)
Ich denke es wäre erheblich sauberer, wenn Du an Stelle von Variablen,  verschiedene Konfigurations-Dateien verwendest. Wie gesagt lässt sich das per Start-Script sehr vereinfachen, z.B. einfach das apachectl Script etwas anpassen für jede Version.

Die allgemeine Konfiguration die bei allen Versionen immer gleich sein wird (vermutlich die Konfigurationen der verschiedenen Module...) kannst Du dann in eine "commonapache.conf" stecken (so nennt Gentoo das), und diese dann per include in die speziellen Konfig-Dateien einbinden. So erreichst Du denselben Effekt, nur finde ich es sauberer.

Die Variablen würde ich eher verwenden, um spezielles Verhalten zu erreichen, oder um bestimmte Module einfach an/aus-schalten zu können.

Grüße
Andreas

[Andreas Korthaus]

Hallo!

Nur so nebenbei, gerade stand in den News auf php.net, dass es eine neue Installationsanleitung für PHP gibt. Das unten von mit verlinkte Posting von Rasmus Lersdorf wurde endlich auch in die FAQ übernommen ;-)

Apache2-Anleitung: http://de3.php.net/manual/de/install.unix.apache2.php

Warum nicht Apache2 in produktiver Umgebung:
http://de3.php.net/manual/en/faq.installation.php#faq.installation.apache2

Wobei ich persönlich dem nur in Bezug auf Multithreading zustimme, Apache2 mit prefork ist in meinen Augen inzwischen durchaus in Ordnung, und soweit ich weiß auch minimal schneller als Apache 1.3.

Was ich besonders nett finde, es gibt sogar Infos für die Installation unter Gentoo Linux: http://de.php.net/manual/en/install.unix.php#install.unix.gentoo
(Du hattest ja Suse, jedenfalls ist die Apache Installation unter Gentoo ganz interessant, denn dort ist die Apache-Konfiguration in meinen Augen recht geschickt aufgebaut.)

Grüße
Andreas

[XaraX]

Guten Morgen,

gibt es eine Möglichkeit statt des "standard english format" (%t) den Timestamp zu protokollieren? Laut Documentation wird das Format durch %{[fromat]}t generiert; auch ist etwas von strftime zu lesen. Welcher Sprache enspringt strftime in dieses Fall nur?

Gruß aus Berlin!
eddi

[Christoph Schnauß]

hallo Eddi,

gibt es eine Möglichkeit statt des "standard english format" (%t) den Timestamp zu protokollieren?

Wie meinst du das? Gib mal bitte kurz ein Beispiel aus deinen logs. Ich habe meine eben mal durchgeschaut, im error_log finde ich:
  [Mon Aug 16 11:24:21 2004]
Und im access_log:
  [16/Aug/2004:11:31:19 +0200]
Es sind also bereits unterschiedliche Formate in den beiden logs.

Laut Documentation wird das Format durch %{[fromat]}t generiert; auch ist etwas von strftime zu lesen. Welcher Sprache enspringt strftime in dieses Fall nur?

In den Apache-Sourcen findest du zum Beispiel in mod_log_config.c folgendes (etwa Zeile 100):
 * %...{format}t:  The time, in the form given by format, which should be in strftime(3) format.
Und als Zusatz:
 * The '...' can be nothing at all (e.g. "%h %u %r %s %b"), or it can
 * indicate conditions for inclusion of the item (which will cause it
 * to be replaced with '-' if the condition is not met).  Note that
 * there is no escaping performed on the strings from %r, %...i and
 * %...o

"strftime" kommt aus C.

Grüße aus Berlin

Christoph S.

[XaraX]

Hallo Christoph :)

gibt es eine Möglichkeit statt des "standard english format" (%t) den Timestamp zu protokollieren?

Wie meinst du das?

Ich hätte gerne (int) Timestamp; also es soll kein datumformatierten String, sondern die Sekundenanzahl seit 01.01.1970 als Wert protokolliert werden.
Die Frage bezieht sich auf das logging von Accessen.

Gib mal bitte kurz ein Beispiel aus deinen logs.
Und im access_log:
  [16/Aug/2004:11:31:19 +0200]

Für:

LogFormat  "%T:%D %{}t %H %m %s %f %a %{USER}e" SchemaName

Erhalte ich im accesfile diesen Eintrag:

0:2491 [16/Aug/2004:12:54:17 +0200] HTTP/1.1 GET 404 /verzeichnis/ 127.0.0.1 eddi

Zur Verständlichkeit -> {USER} wurde vorher durch SetEnv in der Serverkonfigurationsdatei erzeugt.

Es sind also bereits unterschiedliche Formate in den beiden logs.

Laut Documentation wird das Format durch %{[fromat]}t generiert; auch ist etwas von strftime zu lesen. Welcher Sprache enspringt strftime in dieses Fall nur?

In den Apache-Sourcen findest du zum Beispiel in mod_log_config.c folgendes (etwa Zeile 100):

[...]

"strftime" kommt aus C.

Nun wie definiere ich dem guten strftime() nun (im eigentlichen ja) mache gar nichts, da strftime dazu da ist, den Timestamp umzuwandeln.

Gruß aus Berlin!
eddi