Apache konfigurieren

[Andreas Korthaus]

Hallo!

Hier kennen sich ja einige mit der Konfiguration des Apachen aus. Habe jetzt 2 Versionen des Apachen(1 und 2) in /usr/local installiert. Klappt wunderbar. Jetzt weiß ich nur nicht, was ich bei configure sinnvollerweise angeben sollte(Apache 2). Habe mal aus configure --help die Parameter rausgeschreiben die ich sinnvoll finde, aber wie gesagt habe ich keine Ahnung. Was ich brauche ist folgendes:

Ich brauche den Apache nur für ein PHP-Projekt, der Apache soll halt möglichst sicher und performant laufen. Außerdem will ich mod_ssl, mod_rewrite, http_auth, libphp(PHP als Modul), mod_gzip und access-logs verwenden. Vermutlich sollte der Apache so schlank wie möglich sein.

Meine Parameter:

--enable-maintainer-mode
--enable-auth-diges
--enable-isapi
--enable-file-cache
--enable-cache
--enable-disk-cache
--enable-mem-cache
--enable-case-filter
--enable-case-filter-in
--disable-include
--enable-deflate
--enable-mime-magic
--enable-expires
--enable-headers
--enable-unique-id
--enable-proxy
--enable-proxy-connect
--enable-proxy-http
--enable-ssl
--enable-http
--enable-info
--enable-cgi
--enable-cgid
--enable-vhost-alias
--enable-speling
--enable-rewrite
--enable-so
#--with-z=DIR
#--with-ssl=DIR
#--with-mpm=MPM

Jetzt steht nichts im Verzeichnis /modules, heißt also ich muß die Module extra installieren - nur wie? Wo bekomme ich die her?
Und muß ich ein Verzeichnis für SSL und zlib angeben? libssl(openssl) habe ich in /lib gefunden, müßte ich wohl --with-ssl=/lib angeben, oder? zlib finde ich aber nicht, wie finde ich das auf meinem Rechner? Woher weiß ich wo das liegt? Es ist doch garantiert irgendwo bei Redhat Linux 8 standardmäßig dabei.

Jedenfalls funktioniert https://localhost/ nicht. Snd die Module denn in den Sourcen alle drin? Denn da finde ich die irgendwie nicht.

Und was ist mit MPM, sollte ich das ändern? Sollte ich noch weitere Parameter mit einbinden, oder welche von den obigen ausschließen? Auch in Bezug auf PHP, da ist das ja noch eine haarige Angelegenheit, oder?

Zusatzfrage, wenn ich in der httpd.conf "Listen 1080" angebe, dann ist der Server nicht mehr über "localhost" zu erreichen, aber auch nicht über http://localhost:1080, oder 127.0.0.1:1080, wie denn sonst?(getestet mit Mozilla) Habe auch "Listen 127.0.0.1:1080" versucht - erfolglos.

Zusatzfrage2, mit obigen Parametern erhalte ich bei allen möglichen Funktionen(fast bei jeder) bei make und make install:

Function':
/root/httpd-2.0.44/modules/arch/win32/mod_isapi.c:1322: undefined reference to
`SetLastError'
collect2: ld returned 1 exit status
make[1]: *** [httpd] Fehler 1

Was sagt mir das jetzt? Der Apache läuft prima, aber irgendwo scheint es ja Probleme zu geben, oder?

Finde das ganze leider nirgendwo dokumentiert. Bin dankbar für jeden noch so kleinen Tipp, fühle mich nämlich gerade ein wenig wie Alice im Wundeland ;-) Auf alle Fälle will ich es gerne einmal selbst machen, und nichts fertiges verwenden, wenn ich das einmal alles kapiert habe, kann ich das ja später einfach in ein bash-Script schreiben, und dann kann ich mir einfach meine eigene "Installationsroutine" schreiben.

Viele Grüße
Andreas

[Michael Schröpl]

Hi Andreas,

Jetzt weiß ich nur nicht, was ich bei configure sinnvollerweise angeben sollte(Apache 2).

das, was Du brauchst. ;-)

Bei Apache 2 kann ich auch nur raten, an vielen Stellen. Also: Auf geht's ...

Ich brauche den Apache nur für ein PHP-Projekt, der Apache soll halt möglichst sicher und performant laufen. Außerdem will ich mod_ssl, mod_rewrite, http_auth, libphp(PHP als Modul), mod_gzip und access-logs verwenden. Vermutlich sollte der Apache so schlank wie möglich sein.

"schlank" und "mod_rewrite" unter einen Hut zu bekommen ist ein echtes Kunststück. "mod_rewrite" ist bei Apache 1.3 das größte Einzelmodul nach Code-Datei-Umfang (vor mod_include, glaube ich mich zu erinnern); brauchst Du das _wirklich_?

Und mod_gzip für Apache 2 ... hm.

--enable-isapi

Hoppla?

--enable-file-cache
--enable-cache
--enable-disk-cache
--enable-mem-cache

Ich wollte, ich könnte zu den ganzen Apache-2-cache-Modulen schon etwas sagen ... das ist jedenfalls (alles?) Performance-Tuning, nicht Funktionalität.

--disable-include

Kluge Entscheidung. ;-)

--enable-deflate

Das jetzt also doch? Oben las es sich noch anders ... für Apache 2 ist das aber wahrscheinlich kein großer Unterschied.

--enable-mime-magic

Wofür brauchst Du diese Kristallkugel?

--enable-expires
--enable-headers

Beides sinnvoll - aber nur, wenn Du es aktiv und richtig nutzt.

--enable-unique-id

Wofür brauchst Du das?

--enable-proxy
--enable-proxy-connect
--enable-proxy-http

Wofür brauchst Du das? (Der ganze Proxy-Kram ist auch nicht wirklich klein, glaube ich.)

--enable-ssl

Das dürfte auch nicht ganz klein sein - aber Du brauchst es ja.

--enable-http

Hoppla - das sagt mir gerade mal gar nichts ...

--enable-info

Klingt nach mod_info - wofür?

--enable-cgi

Ich habe kein CGI in Deiner Aufgabenstellung gefunden ...

--enable-vhost-alias

Brauchst Du das?

--enable-speling

Oh - die Kristallkugel, die an den URLs herumprobiert, um 404er zu vertuschen. Willst Du das wirklich?

--enable-rewrite

Nun gut ...

--enable-so

Wozu brauchst Du mod_so, wenn Du doch beim Übersetzen einen maßgeschneiderten Apache zusammenbaust?

#--with-z=DIR

Ist da für die zlib? Wenn Du mod_deflate verwenden willst - das nutzt die zlib, die haben nichts Eigenes geschrieben (anders als mod_gzip).

Jetzt steht nichts im Verzeichnis /modules

Wozu auch? Ich dachte, Du willst alles statisch zu einem "httpd" zusammenbinden und fertig.

Und muß ich ein Verzeichnis für SSL und zlib angeben?

Ich denke, ja (beides).

zlib finde ich aber nicht, wie finde ich das auf meinem Rechner?

Hm ... wo sind denn die anderen C-Standardbibliotheken installiert? (/usr/local/lib?)
Geh doch mal mit einem "find / -name libz.a -ls" über die ganze Platte danach suchen ...

Woher weiß ich wo das liegt? Es ist doch garantiert irgendwo bei Redhat Linux 8 standardmäßig dabei.

Hat RedHat eine Funktion, um installierte Pakete anzuzeigen?

Sind die Module denn in den Sourcen alle drin? Denn da finde ich die irgendwie nicht.

Ich verstehe das Apache2-Zusammenbauen noch nicht. Aber bei Apache 1.3 verwende ich mod_so nicht und habe deshalb auch keine *.so-Module herum liegen - ich habe in "bin/httpd" alles drin, was ich brauche.

Und was ist mit MPM, sollte ich das ändern?

Das ist etwas, was Du gründlich lesen solltest, bevor Du es änderst ... das ist wohl eine Wissenschaft für sich.

Sollte ich noch weitere Parameter mit einbinden, oder welche von den obigen ausschließen?

Wenn Du wirklich nur fünf Module brauchst, dann brauchst Du auch nur diese einzubinden.
(Du kannst übrigens mit "httpd -l" nachsehen, was tatsächlich alles eingebunden ist.)

/root/httpd-2.0.44/modules/arch/win32/mod_isapi.c:1322: undefined reference to
`SetLastError'

Da scheint der Linker eine Referenz zu einem Symbol nicht auflösen zu können - wahrscheinlich fehlt irgendwas, das vorher bereits installiert sein muß.

collect2: ld returned 1 exit status
make[1]: *** [httpd] Fehler 1

Brachst Du das ISAPI-Zeug - und wenn ja, wofür? (Das ist doch diese Micro$oft-IIS-Emulation, oder?)

Finde das ganze leider nirgendwo dokumentiert.

(http://httpd.apache.org/docs-2.0/mod/) Buch macht kluch.
Außerdem müßte die Datei "INSTALL" immer noch mit ausgeliefert werden, denke ich mal ...

kann ich das ja später einfach in ein bash-Script schreiben, und dann kann ich mir einfach meine eigene "Installationsroutine" schreiben.

Genau so mache ich das auch.

Viele Grüße
      Michael

[Andreas Korthaus]

Hallo Michael!

Danke für Deine Antwort, ich stehe da wirklich total auf dem Schlauch. Ich habe wohl in der Apache Doku gelesen, da stehen die Module wunderbar erklärt, aber nicht wo ich die herbekomme! Das beste wird sein die wenigen Module die ich brauche mit in den httpd einzukompilieren(geht das auch mit PHP? Bei Apache 1 geht das zumindest.)  Aber ich habe ja jetzzt z.B. --enable-rewrite verwendet, aber ich kann mod_rewrite nicht verwenden.

httpd -l gibt mir folgendes aus

[root@localhost bin]# ./httpd -l
Compiled in modules:
  core.c
  mod_access.c
  mod_auth.c
  mod_include.c
  mod_log_config.c
  mod_env.c
  mod_setenvif.c
  prefork.c
  http_core.c
  mod_mime.c
  mod_status.c
  mod_autoindex.c
  mod_asis.c
  mod_cgi.c
  mod_negotiation.c
  mod_dir.c
  mod_imap.c
  mod_actions.c
  mod_userdir.c
  mod_alias.c
  mod_so.c

Der hlt sich irgendwei kein Stück an mein configure! _kein_ mod_rewrite, dafür mod_include... wieso?

Das war mein configure:
[root@localhost bin]# ./configure --prefix=/usr/local/apache-2.0.44 --enable-auth-diges --enable-isapi --enable-file-cache --enable-cache --enable-disk-cache --enable-mem-cache --enable-case-filter --enable-case-filter-in --disable-include
--enable-deflate --enable-mime-magic --enable-expires --enable-headers --enable-unique-id --enable-proxy --enable-proxy-connect --enable-proxy-http --enable-ssl --enable-http --enable-info --enable-cgi --enable-cgid --enable-vhost-alias --enable-speling --enable-rewrite --enable-so

Bei Apache 2 kann ich auch nur raten, an vielen Stellen. Also: Auf geht's ...

Falls es Dir hilft: ./configure --help > ../apache2.txt: http://knet-systems.de/temp/apache2.txt Das ist die einzige Hilfe die ich zu configure habe, in INSTALL steht so gut wie nichst darüber, halt der Hinweis auf --help, in der Doku steht viel über die Verwendung, nichts über die Installation.

"schlank" und "mod_rewrite" unter einen Hut zu bekommen ist ein echtes Kunststück.

och sagte "möglichst" schlank. mod_rewrite ist das wichtigste Apache-Modul welches ich brauche. Mal was allgemeines, sollte ich möglichs alle Module die ich brauche einkompilieren, oder nur die die ich andauernd brauche? Also rewrite und php?

"mod_rewrite" ist bei Apache 1.3 das größte Einzelmodul nach Code-Datei-Umfang (vor mod_include, glaube ich mich zu erinnern); brauchst Du das _wirklich_?

ja, für meine modulare Struktur.

| Und mod_gzip für Apache 2 ... hm.
mod_deflate ist glaube ich das pendant, daher auch --enable-deflate. Aber davon sehe ich auchs nichts unter httpd -l. Vermutlich braucht er hierfür die zlib, also
--with-z=DIR, nur woher weiß ich in welchem Verzeichnis Rehat diese Lib installiert hat?
Vielleicht /usr/include/zlib.h, oder /lib/modules/2.4.18-14/kernel/lib/zlib_deflate, oder /usr/lib/libz.(a|so)? Ich weiß es nicht.

--enable-isapi

Hoppla?

Ok, weg damit.

--enable-file-cache
--enable-cache
--enable-disk-cache
--enable-mem-cache

Ich wollte, ich könnte zu den ganzen Apache-2-cache-Modulen schon etwas sagen ... das ist jedenfalls (alles?) Performance-Tuning, nicht Funktionalität.

Ja, wenn ich ohne weitgeres Zutun nur durch diese paar Angaben bessere Performance erhalte soll es mir recht sein, die Frage ist ob em tatsächlich so ist!
mod_file_cache
New module in Apache 2.0. This module includes the functionality of mod_mmap_static in Apache 1.3, plus adds further caching abilities.

--disable-include

Kluge Entscheidung. ;-)

Sah der Apache wohl anders ;-)

--enable-deflate

Das jetzt also doch? Oben las es sich noch anders ... für Apache 2 ist das aber wahrscheinlich kein großer Unterschied.

mod_deflate
New module in Apache 2.0. This module allows supporting browsers to request that content be compressed before delivery, saving network bandwidth.

--enable-mime-magic
Wofür brauchst Du diese Kristallkugel?

Keien Ahnung, ich dachte eher so "was schadet sie"?

--enable-expires
--enable-headers
Beides sinnvoll - aber nur, wenn Du es aktiv und richtig nutzt.

Hm ich denek ich brache es nicht, da nur wie gesagt ein PHP Projekt drauf läuft, aber vielleicht für Bilder etc. wiederum andere Dateien dürfen bloß nicht gecached werden.

--enable-unique-id
Wofür brauchst Du das?

Wenn ich eine Unique ID vergeben will ist das doch ein netter salt für mt_rand() in PHP, oder? Muß aber nicht sein.

--enable-proxy
--enable-proxy-connect
--enable-proxy-http
Wofür brauchst Du das? (Der ganze Proxy-Kram ist auch nicht wirklich klein, glaube ich.)

Hast Recht, nicht wirklich ;-)

--enable-ssl

Das dürfte auch nicht ganz klein sein - aber Du brauchst es ja.

Unbedingt. Aber das ist ja schön und gut das ich sage "ENABLE", scheint den Apchen wieder nicht zu stören. ODer das kommt auch davon dass ich --with-ssl=DIR nicht angegeben habe wie oben oben zlib, aber hier ist es vermutlich /usr/lib/libssl.a bzw. /usr/lib/libssl.so, oder?

--enable-http
Hoppla - das sagt mir gerade mal gar nichts ...

mir auch nicht, am besten weg damit.

--enable-info

Klingt nach mod_info - wofür?

weg ;-)

--enable-cgi

Ich habe kein CGI in Deiner Aufgabenstellung gefunden ...

stimmt! Hatte ich auch überlegt, hast Recht.

--enable-vhost-alias
Brauchst Du das?

Ich brauche evtl mehrere Virt-Hosts

--enable-speling
Oh - die Kristallkugel, die an den URLs herumprobiert, um 404er zu vertuschen. Willst Du das wirklich?

Ach sowas, ich denke braucht man nicht.

--enable-rewrite
Nun gut ...

ICH BRAUCHE ES ;-)

--enable-so

Wozu brauchst Du mod_so, wenn Du doch beim Übersetzen einen maßgeschneiderten Apache zusammenbaust?

Ich überlege ob ich selten verwendete Module über DSO lade, so mod_perl z.B. das brauche ich nur zum parsen und schreiben von Excel-Dateien. Udn ich weiß nicht ob sich PHP _überhaupt_ in den httpd einkompilieren läßt.

#--with-z=DIR
Ist da für die zlib? Wenn Du mod_deflate verwenden willst - das nutzt die zlib, die haben nichts Eigenes geschrieben (anders als mod_gzip).

Aber wie ich das verstanden habe macht mod_deflate "exakt" dasselbe wie mod_gzip, oder? mod_gzip gibt es doch nicht für den 2er Apachen, oder?

Und muß ich ein Verzeichnis für SSL und zlib angeben?
Ich denke, ja (beides).

so siehts aus ;-)

zlib finde ich aber nicht, wie finde ich das auf meinem Rechner?

Hm ... wo sind denn die anderen C-Standardbibliotheken installiert? (/usr/local/lib?)
Geh doch mal mit einem "find / -name libz.a -ls" über die ganze Platte danach suchen ...

libz.a also, OK das reicht. .a ist immer für einzukompilierende Module, .so für DSO, oder?

Hat RedHat eine Funktion, um installierte Pakete anzuzeigen?

Alle habe ich noch nicht gefunden, aber ich kann mir noichmal so einen RPM-Manager besorgen, der zeigt das alles an.

Ich verstehe das Apache2-Zusammenbauen noch nicht. Aber bei Apache 1.3 verwende ich mod_so nicht und habe deshalb auch keine *.so-Module herum liegen - ich habe in "bin/httpd" alles drin, was ich brauche.

Ist der Nachteil eine "alles drin was ich brache"-Aachen nur dieser das er für Erweiterungen neu kompiliert werden muß? Sonst ist das doch grundsätzlich schneller, oder?

Und was ist mit MPM, sollte ich das ändern?
Das ist etwas, was Du gründlich lesen solltest, bevor Du es änderst ... das ist wohl eine Wissenschaft für sich.

Ja, halt grundsätzlich als worker-threads oder mit prefork, ich werde letzteres einfach nicht verändern, aber für später -  was ist wohl schneller?

Sollte ich noch weitere Parameter mit einbinden, oder welche von den obigen ausschließen?

Wenn Du wirklich nur fünf Module brauchst, dann brauchst Du auch nur diese einzubinden.
(Du kannst übrigens mit "httpd -l" nachsehen, was tatsächlich alles eingebunden ist.)

ich binde aber nicht nur die Module ein. Es gibt ja auch genügend Parameter zum "Konfigurieren", das ist meine Sorge das mir da was fehlt.

collect2: ld returned 1 exit status
make[1]: *** [httpd] Fehler 1

Brachst Du das ISAPI-Zeug - und wenn ja, wofür? (Das ist doch diese Micro$oft-IIS-Emulation, oder?)

Teufelszeug - SOWAS IST DAS????

Finde das ganze leider nirgendwo dokumentiert.

(http://httpd.apache.org/docs-2.0/mod/) Buch macht kluch.
Außerdem müßte die Datei "INSTALL" immer noch mit ausgeliefert werden, denke ich mal ...

Einem dem das ganze noch nicht so vertraut ist fehlten da irgendwie die wichtigsten Infos, so langsam wird es aber klarer, vielen Dank!

Ich werde auch noch Apache 1 neu kompilieren, da gelten im Prinzip dieselben Regeln, oder? Wenn das mod_gzip Modul ja nicht im Source enthalten ist, und ich es von sourcefourge runterlade, kann ich das trotzdem mit einkompilieren?

Nochmals vielen Dank!

Grüße
Andreas

[Andreas Korthaus]

Hallo Michael!

ich habe es also nochmal probiert mit folgendem configure:

[root@localhost httpd-2.0.44]# ./configure --prefix=/usr/local/apache-2.0.44 --enable-cache --enable-disk-cache --enable-mem-cache --enable-case-filter --enable-case-filter-in --disable-include --enable-deflate --enable-expires --enable-headers --enable-unique-id --enable-ssl --enable-vhost-alias --enable-rewrite --enable-so --with-z=/usr/lib --with-ssl=/usr/lib

Dann erhalte ich

[root@localhost httpd-2.0.44]# /usr/local/apache-2.0.44/bin/httpd -l
Compiled in modules:
  core.c
  mod_access.c
  mod_auth.c
  mod_cache.c
  mod_disk_cache.c
  mod_mem_cache.c
  mod_case_filter.c
  mod_case_filter_in.c
  mod_deflate.c
  mod_log_config.c
  mod_env.c
  mod_expires.c
  mod_headers.c
  mod_unique_id.c
  mod_setenvif.c
  mod_ssl.c
  prefork.c
  http_core.c
  mod_mime.c
  mod_status.c
  mod_autoindex.c
  mod_asis.c
  mod_cgi.c
  mod_vhost_alias.c
  mod_negotiation.c
  mod_dir.c
  mod_imap.c
  mod_actions.c
  mod_userdir.c
  mod_alias.c
  mod_rewrite.c
  mod_so.c

Das sieht ja direkt ganz anders aus, keine Ahnung was ich davor falsch gemacht habe, jedenfalls habe ich jetzt
mod_deflate
mod_rewrite
mod_ssl
mod_so(s.u.)

alles das was ich wollte, sehr schön. Ich habe mir die PHP-Doku... nochmal angesehen, es scheint noch keine Methode zu geben PHP statisch in den Apache2 einzukompilieren, das werde ich dann beim 2er mal versuchen.

Jetzt muß ich noch überlegen was ich davon noch rausschmeißen kann, auf alle Fälle

mod_cgi
mod_imap
mod_status

und mal gucken was noch.

Danke für Deine Hilfe.

Grüße
Andreas

[Michael Schröpl]

Hi Andreas,

"schlank" und "mod_rewrite" unter einen Hut zu bekommen ist ein echtes Kunststück.
och sagte "möglichst" schlank. mod_rewrite ist das wichtigste Apache-Modul welches ich brauche.

Ich habe mod_rewrite noch nie gebraucht ...

Mal was allgemeines, sollte ich möglichs alle Module die ich brauche einkompilieren, oder nur die die ich andauernd brauche? Also rewrite und php?

Was verstehst Du unter "andauernd"? Ist das ein Produktions-Apache oder nur einer für Dich zum "spielen"?

"mod_rewrite" ist bei Apache 1.3 das größte Einzelmodul nach Code-Datei-Umfang (vor mod_include, glaube ich mich zu erinnern); brauchst Du das _wirklich_?
ja, für meine modulare Struktur.

Diese Erklärung überzeugt mich nicht.
Was brauchst Du denn, was Du nicht mit sehr viel billigeren Methoden (Aliasse etc.) umsetzen kannst?

| Und mod_gzip für Apache 2 ... hm.
mod_deflate ist glaube ich das pendant, daher auch --enable-deflate. Aber davon sehe ich auchs nichts unter httpd -l. Vermutlich braucht er hierfür die zlib,

Ja. Definitiv.

--enable-file-cache
--enable-cache
--enable-disk-cache
--enable-mem-cache
Ich wollte, ich könnte zu den ganzen Apache-2-cache-Modulen schon etwas sagen ... das ist jedenfalls (alles?) Performance-Tuning, nicht Funktionalität.
Ja, wenn ich ohne weitgeres Zutun nur durch diese paar Angaben bessere Performance erhalte

"Ohne weiteres Zutun" - nein. Fast alle Module stellen Dir lediglich Direktiven zur Verfügung - es ist dann Dein Job, diese zielgerichtet einzusetzen und damit Deine Aufgabenstellung zu modellieren.

mod_file_cache
New module in Apache 2.0. This module includes the functionality of mod_mmap_static in Apache 1.3, plus adds further caching abilities.

Eben. _Du_ kannst in diesen Cache Dinge laden - tust Du das?

--enable-deflate
Das jetzt also doch? Oben las es sich noch anders ... für Apache 2 ist das aber wahrscheinlich kein großer Unterschied.
mod_deflate
New module in Apache 2.0. This module allows supporting browsers to request that content be compressed before delivery, saving network bandwidth.

Yep - aber Du hattest oben "mod_gzip" genannt, nicht "mod_deflate".

--enable-expires
--enable-headers
Beides sinnvoll - aber nur, wenn Du es aktiv und richtig nutzt.
Hm ich denek ich brache es nicht, da nur wie gesagt ein PHP Projekt drauf läuft, aber vielleicht für Bilder etc. wiederum andere Dateien dürfen bloß nicht gecached werden.

Bilder, JavaScript, CSS, HTML ... sogar PHP-Ausgaben kann der Browser cachen. Es ist Dein Job, Dir ein Konzept der Lebensdauer für jede einzelne Seite zu überlegen, wenn Du dem Cache erklären willst, wie er am effizientesten mit Deinen Seiten umgehen kann.

--enable-http
Hoppla - das sagt mir gerade mal gar nichts ...
mir auch nicht, am besten weg damit.

So hatte ich das nicht gemeint. Ich bin mir bloß keines Moduls "mod_http" bewußt ...

--enable-rewrite
Nun gut ...
ICH BRAUCHE ES ;-)

Siehe oben.

--enable-so
Wozu brauchst Du mod_so, wenn Du doch beim Übersetzen einen maßgeschneiderten Apache zusammenbaust?
Ich überlege ob ich selten verwendete Module über DSO lade, so mod_perl z.B. das brauche ich nur zum parsen und schreiben von Excel-Dateien. Udn ich weiß nicht ob sich PHP _überhaupt_ in den httpd einkompilieren läßt.

Probiere es aus.

#--with-z=DIR
Ist da für die zlib? Wenn Du mod_deflate verwenden willst - das nutzt die zlib, die haben nichts Eigenes geschrieben (anders als mod_gzip).
Aber wie ich das verstanden habe macht mod_deflate "exakt" dasselbe wie mod_gzip, oder?

Wenn Du nur das Ergebnis betrachtest - ja (beinahe - modulo "Vary:"-Header).

Aber _wie_ das Ergebnis zustande kommt, d. h. wie fein Du beeinflussen kannst, wann was warum komprimiert ausgeliefert wird oder nicht, wie performant die Komprimierung erfolgt, _wann_ überhaupt komprimiert wird (mod_gzip 1.3.26.1a hat seinen eigenen Cache) usw., da kann mod_deflate nicht mithalten. Das ist eben ein reiner, "dummer" Komprimierungsfilter.

mod_gzip gibt es doch nicht für den 2er Apachen, oder?

Doch, das gibt es: http://www.pcp-computer.de/gkn/apache/httpd-2.0/win32/modules/
mod_gzip ist ja ursprünglich überhaupt erst für Apache 2.0 geschrieben und nach 1.3 zurück portiert worden, weil Apache 2 jahrelang nicht in die Gänge kam und ständig alle internen APIs inkompatibel geändert wurden ...

Geh doch mal mit einem "find / -name libz.a -ls" über die ganze Platte danach suchen ...
libz.a also, OK das reicht. .a ist immer für einzukompilierende Module, .so für DSO, oder?

Es kann sein, daß beides plattformabhängig ist. Bei mir auf Solaris heißen die während der Apache-Übersetzung lokal entstehenden Bibliotheken jedenfalls "lib*.a" und der Inhalt von /usr/local/lib ebenfalls; die Shared Objects können auf Windows beispielsweise beliebig heißen (mod_gzip funktioniert sowohl als *.so wie auch als *.dll mit demselben Inhalt - sofern die LoadModule-Direktive entsprechend aussieht).

Ist der Nachteil eine "alles drin was ich brache"-Aachen nur dieser das er für Erweiterungen neu kompiliert werden muß? Sonst ist das doch grundsätzlich schneller, oder?

Die *.so-Schnittstelle soll laut Dokumentation in der Tat ein paar Prozente langsamer sein. Auch das Starten des Apache wird durch das Nachladen der shared objects natürlich langsamer, aber das dürfte ziemlich unwichtig sein.

Und was ist mit MPM, sollte ich das ändern?
Das ist etwas, was Du gründlich lesen solltest, bevor Du es änderst ... das ist wohl eine Wissenschaft für sich.
Ja, halt grundsätzlich als worker-threads oder mit prefork, ich werde letzteres einfach nicht verändern, aber für später -  was ist wohl schneller?

Da mußt Du Dich an einen Apache2-Experten wenden - nicht an mich.

Wenn Du wirklich nur fünf Module brauchst, dann brauchst Du auch nur diese einzubinden.
(Du kannst übrigens mit "httpd -l" nachsehen, was tatsächlich alles eingebunden ist.)
ich binde aber nicht nur die Module ein. Es gibt ja auch genügend Parameter zum "Konfigurieren", das ist meine Sorge das mir da was fehlt.

Das merkst Du dann schon, wenn das Linken nicht funktioniert ... ;-)

Ich werde auch noch Apache 1 neu kompilieren, da gelten im Prinzip dieselben Regeln, oder?

Ja. Ich habe mir insbesondere die httpd.conf in ein System von etwa 20 Include-Dateien zerschlagen - soweit wie möglich alles nach Modulen sortiert, in bestimmten Teilen nach "features" (wo ich Direktiven verschiedener Module brauche, um thematisch zusammengehörige Dinge zu realisieren).
Deshalb weiß ich ja überhaupt, welche Module ich brauche und welche nicht - das ist einmalig ziemlich viel Arbeit, aber man lernt den Apache dabei richtig gut kennen.

Meine Virtual-Host-Abschnitte bestehen inzwischen fast nur noch aus Include-Anweisungen dieser "Bausteine".

Wenn das mod_gzip Modul ja nicht im Source enthalten ist, und ich es von sourcefourge runterlade, kann ich das trotzdem mit einkompilieren?

Ja, kannst Du. Falls Du auf einer Plattform arbeitest, für die es schon ein shared object gibt (BSD, Linux, Solaris), könntest Du auch dieses verwenden.

Viele Grüße
      Michael

[Andreas Korthaus]

Hallo!

Mal was allgemeines, sollte ich möglichs alle Module die ich brauche einkompilieren, oder nur die die ich andauernd brauche? Also rewrite und php?

Was verstehst Du unter "andauernd"? Ist das ein Produktions-Apache oder nur einer für Dich zum "spielen"?

Ich spiele hier bei mir rum, aber ich will genau dei Konfiguration in einigen Wochen auf einem Produktions-Server einsetzen. "andauernd" ist so eine Sache. Es haben nur bestimmte Leute Zugriff, aber das können schonmal ein paar sein, und wenn dann meist alle zur gleichen Zeit, also muß ich diese peaks aushalten, udn da habe ich mal grob überschlagen, sind es mit massig reservern höchtens 100 Requests pro Sekunde, aber die gehen dafür fast alle an wirklich komplexe PHP-Scripte, wo viel eingebunden wird(halt eigene modulare Struktur(konfdaten, userdaten, PEAR, PEAR::Auth, PEar::DB, Smarty(template-Engine)...)), das in jedem Script. Die Modularität war hier erheblich wichtiger als die Performance, aber trotzdem sollte das Teil nicht bei 50 gleichzeitigen anwesenden Anwendern zusammenbrechen ;-)
Der Server an sich ist einigermaßen Leistungsfähig, weiß jetzt nicht genau, aber eine X86 Architektur mit 500MB RAM und ich vermute mit einem halbwegs neuen PIII. Das weiß ich zur Zeit aber alles noch nicht genau. Dafür steht der komplette Server nur hierfür zur Verfügung.   Als OS kommt die Server-Version von RedHat Linux 7.3 oder 8.0. Ich habe jetz euin bisschen in  einer PHP-Liste rumgemailt, und die raten ganz entschieden von Apache 2 ab. Mit prefork versetzt man den Apachen in einen "apache-1-modus" so zu sagen, man hat also keinen Vorteil von Apache2, nur alle Nachteile. Außerdem kann ich PHP da definitiv nicht mit einkompilieren, udn genausowenig meinen favorisierten PHP-Cache verwenden. Spricht also nichts wirklich dafür ;-)

"mod_rewrite" ist bei Apache 1.3 das größte Einzelmodul nach Code-Datei-Umfang (vor mod_include, glaube ich mich zu erinnern); brauchst Du das _wirklich_?
ja, für meine modulare Struktur.

Diese Erklärung überzeugt mich nicht.
Was brauchst Du denn, was Du nicht mit sehr viel billigeren Methoden (Aliasse etc.) umsetzen kannst?

Hatte das ja oben kurz angeschnitten. _Alle_(außer images, index.php) Requests werden auf ein Script "index.php" umgeleitet, mit dem ursprünglichen Request als GET-Parameter. Dann entscheidet dieses Script was pasieren soll, stellt die Configre-,Request-...Variablen über eine Schnittstelle zur Verfügung, führt die Authentifikation durch, läd eine Error-Klasse, PEAR, ggfs. Smarty, läd entsprechend dem Request Module und diese dann ein Template und gibt dieses aus...

Das ganze war notwendig, da die Software Verschieden Benutzerebenen und unabhängige -Bereiche braucht, dazu merhsprachigkeit, und einfach hinzufügbare und entfernbare Plugins, die sich unterschiedlich auf die Benutzer auswirken(erweiterung der Menüstruktur(Userabhängig), zusätzliche Seiten und Scripte, Rechte...). das habe ich hier im Forum in einigen sehr großen und für mich sehr lehrreichen Threads vor allem mit Christian Seilers, Christian Kruses und Sven Rautenbergs(hoffe habe niemanden vergessen, wenn doch sorry :-( ) Hilfe entwickelt. Ob das so optimal ist kann ich noch nicht sagen, ich habe da halt überhaupt keine Erfahrung. Bitte sag mir jetzt nicht das dieser Aufbau totaler Quatsch ist :-)

Ohne weiteres Zutun" - nein. Fast alle Module stellen Dir lediglich Direktiven zur Verfügung - es ist dann Dein Job, diese zielgerichtet einzusetzen und damit Deine Aufgabenstellung zu modellieren.

Bilder, JavaScript, CSS, HTML ... sogar PHP-Ausgaben kann der Browser cachen. Es ist Dein Job, Dir ein Konzept der Lebensdauer für jede einzelne Seite zu überlegen, wenn Du dem Cache erklären willst, wie er am effizientesten mit Deinen Seiten umgehen kann.

Bei PHP-Ausgabe nicht ganz so einfach, siehe mein Struktur, vielleicht sollte ich solcher Headere hier lieber in PHP generieren?!

So hatte ich das nicht gemeint. Ich bin mir bloß keines Moduls "mod_http" bewußt ...

-enable-http           HTTP protocol handling

sagt mir nicht allzuviel, und finde es nicht in der Doku, ist auch egal, ich brauche es bestimmt nicht! Ich bin anfangs nur so nach namen u. Beschreibung gegangen, "könnte man vielleicht gebrauchen...".

Ich überlege ob ich selten verwendete Module über DSO lade, so mod_perl z.B. das brauche ich nur zum parsen und schreiben von Excel-Dateien.

Wie schätzt Du das ein, sollte man (bei Apache 1) Module, auch wennm an sie seltener braucht mit einkompilieren? Wi eist das theoretisch? Vermutlich verlangsamt jedes einzelne Modul den Apache ein Stück, die Frage ist ob das beio DSO oder static genau gleich ist, oder ob DSO Module weniger ins Gewicht fallen, da sie ja nicht immer "mitgeschleppt" verden müssen.

Doch, das gibt es: http://www.pcp-computer.de/gkn/apache/httpd-2.0/win32/modules/
mod_gzip ist ja ursprünglich überhaupt erst für Apache 2.0 geschrieben und nach 1.3 zurück portiert worden, weil Apache 2 jahrelang nicht in die Gänge kam und ständig alle internen APIs inkompatibel geändert wurden ...

Würdest Du mod_gzip immer mod_deflate vorziehen? Sowohl Apache 1 als auch 2? Ich habe für das Projekt keine einzige HTML-Datei, die ein Cache speichern könnte. Meine Seiten ändern sich fast alle andauernd, manche sogar bei jedem Request.

Da mußt Du Dich an einen Apache2-Experten wenden - nicht an mich.

Daher poste ich ja hier und schreibe Dir keine Mail ;-)

Wenn das mod_gzip Modul ja nicht im Source enthalten ist, und ich es von sourcefourge runterlade, kann ich das trotzdem mit einkompilieren?

Ja, kannst Du. Falls Du auf einer Plattform arbeitest, für die es schon ein shared object gibt (BSD, Linux, Solaris), könntest Du auch dieses verwenden.

Aber dann muss ich es ja wieder über DSO laden, ich will es doch statisch einkompilieren!

Danke vielmals für die Hilfe!

Grüße
Andreas

PS: Gegen PHP war der Apache richtig unproblematisch ;-)

[Michael Schröpl]

Hi Andreas,

ja, für meine modulare Struktur.
Diese Erklärung überzeugt mich nicht.
Was brauchst Du denn, was Du nicht mit sehr viel billigeren Methoden (Aliasse etc.) umsetzen kannst?
Hatte das ja oben kurz angeschnitten. _Alle_(außer images, index.php) Requests werden auf ein Script "index.php" umgeleitet, mit dem ursprünglichen Request als GET-Parameter.

was hältst Du zu diesem Zweck von der Methode, die ich bei gzip_cnc verwende?
   http://www.schroepl.net/projekte/gzip_cnc/install.htm#handler
_Ich_ brauche kein mod_rewrite, um alle Requests auf mich umzuleiten ...

Bilder, JavaScript, CSS, HTML ... sogar PHP-Ausgaben kann der Browser cachen. Es ist Dein Job, Dir ein Konzept der Lebensdauer für jede einzelne Seite zu überlegen, wenn Du dem Cache erklären willst, wie er am effizientesten mit Deinen Seiten umgehen kann.
Bei PHP-Ausgabe nicht ganz so einfach, siehe mein Struktur, vielleicht sollte ich solcher Headere hier lieber in PHP generieren?!

Wahrscheinlich ja - weil Du dort genauer weißt, welche Eigenschaften die jeweilige Seite hat. (Möglicherweise brauchst Du ja Dinge wie "Cache-Control: private" bei personalisierten Seiten?)

So hatte ich das nicht gemeint. Ich bin mir bloß keines Moduls "mod_http" bewußt ...
-enable-http           HTTP protocol handling
sagt mir nicht allzuviel, und finde es nicht in der Doku, ist auch egal, ich brauche es bestimmt nicht!

Naja, ein HTTP-Server, der kein HTTP-Protokoll behandeln kann ... hm ... ;-)

Ich überlege ob ich selten verwendete Module über DSO lade, so mod_perl z.B. das brauche ich nur zum parsen und schreiben von Excel-Dateien.
Wie schätzt Du das ein, sollte man (bei Apache 1) Module, auch wennm an sie seltener braucht mit einkompilieren?

Ich finde, das hängt davon ab, wieviel Angst Du vor einem erneuten Übersetzen hast. Wenn keine, dann übersetze - wenn viel, dann verwende mod_so.

Vermutlich verlangsamt jedes einzelne Modul den Apache ein Stück, die Frage ist ob das beio DSO oder static genau gleich ist, oder ob DSO Module weniger ins Gewicht fallen, da sie ja nicht immer "mitgeschleppt" verden müssen.

Module mod_so

Summary

This is an experimental module.

;-)

Ansonsten: http://httpd.apache.org/docs/dso.html

Doch, das gibt es: http://www.pcp-computer.de/gkn/apache/httpd-2.0/win32/modules/
mod_gzip ist ja ursprünglich überhaupt erst für Apache 2.0 geschrieben und nach 1.3 zurück portiert worden, weil Apache 2 jahrelang nicht in die Gänge kam und ständig alle internen APIs inkompatibel geändert wurden ...
Würdest Du mod_gzip immer mod_deflate vorziehen?

Bei Apache 1.3 stellt sich diese Frage nicht; mod_gzip für Apache 2.0 ist sehr viel älter als mod_gzip für Apache 1.3 (weil niemand die ganzen 1.3.19+-Features nach Apache 2 portiert hat), da kommt es wohl darauf an, ob ich mit hinreichend vielen Apache2-Direktiven-Kenntnissen die ggf. erforderlichen Bedingungen so implementieren und die notwendigen HTTP-Header so erzeugen kann, wie ich das brauche.
mod_deflate macht einfach nur die Komprimierung und sonst nichts - wenn man wirklich nicht mehr braucht (also beispielsweise kaputten Browsern gnadenlos komprimierte Seiten um die Ohren hauen will), dann ist das okay.

Sowohl Apache 1 als auch 2? Ich habe für das Projekt keine einzige HTML-Datei, die ein Cache speichern könnte. Meine Seiten ändern sich fast alle andauernd, manche sogar bei jedem Request.

Selbst dann ist die Frage, ob sich der tatsächliche Inhalt signifikant ändert.
Ich sende selbst bei meinen Suchmaschinen HTTP-Header mit, damit ein "vor" und "zurück" im Browser nicht denselben Datenbank-Zugriff noch einmal auslöst ... zumal dann, wenn ich weiß, daß sich das Ergebnis intraday gar nicht ändern _kann_.

Wenn das mod_gzip Modul ja nicht im Source enthalten ist, und ich es von sourcefourge runterlade, kann ich das trotzdem mit einkompilieren?
Ja, kannst Du. Falls Du auf einer Plattform arbeitest, für die es schon ein shared object gibt (BSD, Linux, Solaris), könntest Du auch dieses verwenden.
Aber dann muss ich es ja wieder über DSO laden, ich will es doch statisch einkompilieren!

Das würde ich auch vorziehen.

Viele Grüße
      Michael

[Andreas Korthaus]

Hallo!

was hältst Du zu diesem Zweck von der Methode, die ich bei gzip_cnc verwende?
   http://www.schroepl.net/projekte/gzip_cnc/install.htm#handler
_Ich_ brauche kein mod_rewrite, um alle Requests auf mich umzuleiten ...

Oh! Sieht interessant aus! Aber habe ich da in dem Script dann auch Zugriff auf den Ursprünglichen Request, inkl. Parameter? Den zugriff hätte ich dann schon gerne in dem mit Action angegebenen CGI-Script! Geht das?

Und mod_action ist erheblich schlanker?
Interesante Idee!

Grüße
Andreas

[Michael Schröpl]

Hi Andreas,

_Ich_ brauche kein mod_rewrite, um alle Requests auf mich umzuleiten ...
Oh! Sieht interessant aus! Aber habe ich da in dem Script dann auch Zugriff auf den Ursprünglichen Request, inkl. Parameter? Den zugriff hätte ich dann schon gerne in dem mit Action angegebenen CGI-Script! Geht das?

Ich fürchte, es wird für Deinen Fall nicht funktionieren, weil der Handler ja selbst keine HTTP-Requests mehr ausführt, sondern nur noch Datei-Inhalte liest.

Viele Grüße
      Michael