Installation von mod_gzip

Die Installation tatsächlich durchzuführen ist nicht schwer, aber die zu den Anforderungen der eigenen Apache-Installation am besten passende Methode herauszufinden, das kann etwas Zeit kosten.

Es wird daher ausdrücklich empfohlen, dieses Kapitel vollständig durchzulesen und sich über die jeweiligen Vor- und Nachteile der verschiedenen Möglichkeiten bewußt zu werden, bevor die Betriebsmethode festgelegt und die Installation durchgeführt wird.

Das vorliegende Dokument geht insbesondere auf die interne Arbeitungsweise von mod_gzip als Apache-Modul ein und vermittelt Informationen, die beim Verständnis von mod_gzips Auswertungsverfahren für Konfigurations-Direktiven hilfreich sein können.

Grundlagen

Einleitung

Der Apache-Webserver unterstützt zwei verschiedene Methoden zur Einbindung eines Moduls in seinen Programmcode:

Je nach dem verwendeten Betriebskonzept des Apache-Servers und den gegebenen Voraussetzungen muß

  1. eine dieser beiden Betriebsmethoden für mod_gzip festgelegt und
  2. die für diese Methode erforderliche Menge von Dateien heruntergeladen

werden.

Statische Einbindung eines Apache-Moduls

Durch eine statische Einbindung wird das Modul zu einem dauerhaften Bestandteil des gebundenen Binär-Programms httpd, welches den Apache-Server realisiert.

Hierfür muß der Quelltext des Apache-Servers

werden.

Normalerweise wird jeder Administrator einen anderen, individuell auf seine Bedürfnisse abgestimmten Funktionsumfang seines Apache-Servers verwenden wollen; daher erscheint es nicht praktikabel, hierfür fertig lauffähige Programmdateien für eine Vielzahl von Plattformen zum Download anzubieten.

Dynamische Einbindung eines Apache-Moduls

Durch eine dynamische Einbindung kann das Modul beim Start der Apache-Prozesse als shared object aus einer separaten Modul-Datei nachgeladen werden.

Hierfür muß

werden.

Die Struktur des Modul-Quelltextes von mod_gzip

Die meisten Apache-Module bestehen aus einer einzigen Quelltext-Datei. Diese Datei kann durch einen Aufruf des Programms apxs (mit entsprechenden Parameterwerten) übersetzt werden; für die Installation des so entstandenen shared object wäre ein weiterer Aufruf von apxs (mit anderen Parameterwerten) erforderlich.

Seit der Version 1.3.26.1a ist der Quelltext von mod_gzip in drei separate Dateien aufgeteilt:

Diese Struktur des Quelltextes macht die Pflege von mod_gzip etwas einfacher - und die Installation ein bißchen komplizierter (weil nun mehrere Quelltextdateien übersetzt werden müssen statt nur einer einzigen). Deshalb liefert mod_gzip nun Makefiles mit, um diesen Installationsvorgang zu vereinfachen.

Download

Je nachdem, welches der oben genannten Betriebskonzepte eingesetzt werden soll, sind unterschiedliche (für den jeweiligen Einsatzzweck passende) Dateien zu verwenden.

Zum Zeitpunkt der Erstellung dieser Dokumentation sind folgende Dateien zur jeweiligen mod_gzip-Version auf der arrowDownload-Seite des Projekts mod_gzip verfügbar:

Falls mod_gzip mit dynamischer Einbindung auf einer anderen Plattform eingesetzt werden soll, muß die Modul-Datei für diese Plattform vom Administrator erstellt werden.

Statische Einbindung von mod_gzip

Die normale Übersetzung des Apache-Webservers

Das von der Apache Group dokumentierte Verfahren zur Installation des Apache-Webservers auf einer UNIX-Maschine lautet (in der Kurzfassung):

  1. Archiv mit dem Apache-Quelltext aus dem WWW laden
  2. Archiv auspacken
  3. in das im vorherigen Schritt entstandene Verzeichnis positionieren
  4. Datei INSTALL lesen und verstehen
  5. Shell-Skript ./configure mit den passenden Parameterwerten aufrufen (das bewirkt die Erzeugung von Makefile-Dateien in zahlreichen Unterverzeichnissen)
  6. make install (das bewirkt die Übersetzung und Installation des Apache-Servers samt dessen Online-Dokumentation)

Wenn der Apache-Webserver auf diese Weise erzeugt wird, dann werden die mitgelieferten Module normalerweise statische Bestandteile der erzeugten Programmdatei httpd im Apache-Programmverzeichnis - sofern man nicht bei den Parametern des configure-Aufrufs etwas anderes angegeben hat.

(Der tatsächliche Aufruf von configure kann - je nach dem Grad der Abweichung von den Parameter-Standardwerten - sehr umfangreich werden. Ich empfehle, diesen Aufruf selbst in einem kleinen Shell-Skript abzuspeichern, um damit gleichzeitig die Art und Weise der durchgeführten Installation zu dokumentieren.)

Die Einbindung von mod_gzip in den Apache-Quelltext

Der Quelltexte der offiziellen Apache-Module ist im Unterverzeichnis src/modules des entpackten tar-Archivs der Apache-Software enthalten.

Um mod_gzip mit diesem Mechanismus wie ein Apache-Standardmodul zu behandeln, sind folgende Vorbereitungen erforderlich:

  1. Inhalt des Download-Archivs mit dem mod_gzip-Quelltext dekomprimieren und entpacken (dabei entsteht ein Verzeichnis mod_gzip-versionnumber),
  2. Verzeichnis src/modules/gzip innerhalb des Verzeichnisbaums des Apache-Quelltextes neu anlegen,
  3. Alle Dateien mit den Endungen *.c, *.h und *.tmpl in dieses neue gzip-Verzeichnis kopieren.

Anschließend ist der configure-Aufruf um den Parameter --activate-module=src/modules/gzip/mod_gzip.c zu erweitern. Nun findet das configure-Skript den mod_gzip-Quelltext und erzeugt aus der mitgelieferten Datei Makefile.tmpl eine passende Makefile-Datei - angezeigt durch die Meldungen

 + activated gzip module (modules/gzip/mod_gzip.c)

und

Creating Makefile in src/modules/gzip

- letzteres genau wie bei Apaches eigenen Modulen. (Das von mod_gzip mitgelieferte Makefile ist für diese Art der Installation nicht geeignet - es ist nur für die Erzeugung einer shared object-Datei verwendbar.)

Nun verläuft die Apache-Installation wie üblich - und mod_gzip wird wie ein normales Apache-Modul behandelt.

configure weiß allerdings, daß ein mit --activate-module eingebundenes Modul ein Fremdprodukt mit wahrscheinlich besonderen Anforderungen ist, und lädt mod_gzip daher automatisch ganz oben auf den Modul-Stapel, so daß es vor allen anderen Modulen den Zugriff auf einen ankommenden HTTP-Request bekommt - genau das, was mod_gzip auch dringend braucht.

Auf manchen Betriebssystemplattformen scheint Apaches configure den Wert der Environment-Variablen $(LIBEXT) nicht automatisch auf .a zu setzen. In diesem Falle wird die Übersetzung von mod_gzip scheitern. Die Ursache für dieses Verhalten ist derzeit nicht nachvollziehbar; als Notlösung hilft, innerhalb der mitgelieferten Datei Makefile.tmpl die Zeile

LIB=libgzip.$(LIBEXT)

durch

LIB=libgzip.a

zu ersetzen, also diesen Wert manuell einzutragen.

Achten Sie darauf, für diesen Schritt einen Editor zu verwenden, der Tabulator-Zeichen nicht in Leerzeichen umwandelt!

(Testen: Was passiert bei der Einbindung mehrerer Fremdmodule mit --activate-module? Ist dann die Reihenfolge der Parameter-Angaben relevant?)

Überprüfen, ob mod_gzip korrekt eingebunden wurde

Zur Überprüfung, ob mod_gzip tatsächlich wie gewünscht in den Apache-Programmcode eingebunden wurde, stellt der Apache-Server das Kommando httpd -l zur Verfügung. Dabei wird die Liste aller eingebundenen Module angezeigt (in der Reihenfolge, in der sie geladen werden); mod_gzip.c sollte dabei der letzte angezeigte Eintrag sein.

Dynamische Einbindung von mod_gzip

Das Konzept nachladbarer Apache-Module

Der Apache-Webserver unterstützt das Konzept nachladbarer Module.

Fast jedes Apache-Modul kann

Der Umgang mit nachladbaren Modulen erfordert zusätzliche Kenntnisse über die Apache-Konfiguration (weil die Reihenfolge, in welcher diese Module geladen werden, für deren Funktionsfähigkeit signifikant sein kann), aber es ermöglicht eine Änderung des Code-Umfangs des Apache-Servers, ohne dessen Programmcode neu übersetzen zu müssen.

Auf Plattformen wie Windows (wo nur die wenigsten Apache-Administratoren eine C-Entwicklungsumgebung verfügbar haben, um den Apache-Code übersetzen und binden zu können) ist die Verwendung nachladbarer Module oftmals die einzige Möglichkeit, den Funktionsumfang des Apache-Servers zu erweitern.

Die Dokumentation zu Apache 1.3 bietet folgende Artikel zu diesem Thema:

Direktive zum Nachladen von mod_gzip

Um mod_gzip dem Apache-Code dynamisch hinzuzufügen, ist eine der folgenden Konfigurations-Direktiven erforderlich:

# ---------------------------------------------------------------------
# DLL laden / Windows:
  LoadModule gzip_module modules/ApacheModuleGzip.dll
# ---------------------------------------------------------------------
# DSO laden / UNIX:
  LoadModule gzip_module modules/mod_gzip.so
# ---------------------------------------------------------------------
# (keines von beiden, falls Modul statisch eingebunden)
# ---------------------------------------------------------------------

Der tatsächliche Dateiname ist dabei frei wählbar - er muß lediglich mit dem Namen der tatsächlich vorliegenden Datei übereinstimmen. Dieser wiederum kann von der Betriebssystem-Plattform und sogar von der verwendeten Kompilierungsmethode dieses Moduls abhängen - in diesem Falle ist entweder die genannte Direktive entsprechend anzupassen oder die Datei entsprechend umzubenennen.

Die Verwaltung von Modulen durch Apache 1.3

Der Apache-Server kann eine beliebige Anzahl von Modulen dynamisch nachladen. Dabei werden die entsprechenden LoadModule-Direktiven in der Reihenfolge ihrer Angabe innerhalb der Konfigurationsdatei ausgewertet.

Die geladenen Module werden allerdings auf einen Stapel innerhalb des Arbeitsspeichers geladen: Dasjenige Modul, welches als letztes geladen wurde, erhält als erstes den Zugriff auf die Bearbeitung der jeweiligen HTTP-Anforderung an den Apache-Webserver - und kann dann entscheiden, ob es sich für die Bearbeitung dieser Anforderung als zuständig betrachtet oder nicht.

Von allen in Frage kommenden Modulen kann bei Apache 1.3 nur ein einziges für die Bearbeitung einer Anforderung zuständig sein - nachfolgende Module werden gar nicht mehr gefragt.

Die Einbindung von mod_gzip in die Auswertung einer Anforderung durch Apache

Damit mod_gzip dennoch die Ausgaben beliebiger Module weiter verarbeiten kann, muß es also etwas tun, was der Architektur des Apache 1.3 eigentlich widerspricht: Es muß eine Anforderung 'bearbeiten', aber anschließend die Zuständigkeit für die Bearbeitung dieser Anforderung zurückweisen. Nur dadurch kann auch das eigentlich zuständige Modul für die inhaltliche Bearbeitung der Anforderung überhaupt noch vom Apache-Server aktiviert werden.

In dieser ersten Phase besteht die 'Bearbeitung' der Anforderung durch mod_gzip nicht darin, den auszuliefernden Inhalt der angeforderten Seite zu komprimieren - weil dieser ja noch gar nicht existiert, er muß ja erst noch durch ein anderes Modul erzeugt werden! Statt dessen sorgt mod_gzip zu diesem Zeitpunkt lediglich dafür, daß es nach der Erzeugung des Seiteninhalts noch einmal gefragt werden wird, ob es etwas tun möchte. Erst in dieser zweiten Phase seiner Aktivierung (wo dann bereits der Inhalt der HTTP-Antwort vorliegt) kann mod_gzip dann seine wesentliche Aufgabe, nämlich die Komprimierung des Inhalts des HTTP-Anwortpakets (und die Modifikation bestimmter HTTP-Header), erfüllen.

Diese von mod_gzip durchgeführte 'Anmeldung' für die spätere Nachverarbeitung der HTTP-Anforderung ist jedoch nur dann erforderlich, wenn mod_gzip nicht bereits zu diesem Zeitpunkt erkennen kann, daß es sich für die Verarbeitung des Inhalts der Antwort definitiv nicht interessieren wird.

Daher führt mod_gzip bereits in dieser ersten Phase einen Teil der Auswertung der in der Apache-Konfiguration spezifizierten Filter-Direktiven durch: Es prüft diejenigen Regeln, bei denen dies allein aufgrund der Beschreibung der Anforderung (d. h. des Inhalts der entsprechenden HTTP-Header) bereits möglich ist. Dies betrifft die mod_gzip_item_include/mod_gzip_item_exclude-Regeln der Art

Falls die Auswertung dieser Filterregeln bereits ergibt, daß das Ergebnis dieser Anforderung nicht komprimiert werden darf, d. h. wenn

dann ist es für mod_gzip nicht erforderlich, nach der Erzeugung des Antwortpakets die restlichen Regeln zu prüfen - und dies geschieht dann auch nicht mehr, weil mod_gzip sich das Ergebnis der ersten Auswertungsphase für jede Anforderung merkt und in diesem Fall die zweite Phase sofort beendet.

Ansonsten prüft mod_gzip in der zweiten Phase seiner Verarbeitung die verbleibenden Filterregeln, die nur aufgrund des tatsächlichen Inhalts des erzeugten Antwortpakets ausgewertet werden können:

Zusätzlich werden nun noch einige weitere Bedingungen geprüft, etwa basierend auf der Größe des Antwortpakets für die Direktiven mod_gzip_minimum_file_size bzw. mod_gzip_maximum_file_size.

Und erst wenn alle diese Prüfungen positiv ausgefallen sind, wird tatsächlich die Komprimierung des Antwortpakets durchgeführt.

Die Position von mod_gzip innerhalb der Lade-Reihenfolge aller Apache-Module

Um alle zuvor beschriebenen Tätigkeiten durchführen zu können, muß das Modul mod_gzip vor jedem anderen Apache-Modul, dessen Ausgabe es verarbeiten können soll, den Zugriff auf die Bearbeitung der HTTP-Anforderung erhalten. Aufgrund der umgekehrten Reihenfolge des Zugriffs aller Apache-Module auf die Verarbeitung einer Anforderung sollte mod_gzip daher als letztes aller Apache-Module geladen werden.

Bei der statischen Einbindung wird diese Modul-Reihenfolge durch den 'Bauplan' des httpd-Programms während der Übersetzung des Apache-Quelltexts festgelegt. Das von der Apache Group mitgelieferte Verfahren zur Übersetzung des Apache-Quelltextes, aktiviert durch das Shell-Skript configure, kennt zwar alle Abhängigkeiten zwischen den mitgelieferten Modulen (und stellt eine entsprechende Anordnung dieser Module sicher), nicht aber die Bedürfnisse von Fremdmodulen wie mod_gzip, welche durch den configure-Parameter --add-module=file in den Übersetzungsvorgang einbezogen werden. Um diesen Fremdmodulen ein Maximum an Einfluß zu ermöglichen, werden solche Module als letzte Module auf den Modul-Stapel geladen.

Falls also mod_gzip als einziges Fremdmodul in einen Apache-Server mit integriert werden soll, tut configure automatisch das Richtige; falls mehrere Fremdmodule verwendet werden sollen, ist der Administrator für die Anordnung dieser Module verantwortlich (vielleicht durch die Reihenfolge seiner --add-module=-Angaben? Ich habe das noch nicht ausprobiert).

Übersetzen von mod_gzip mit apxs

Die Funktion des Apache-Übersetzungs-Hilfsprogramms apxs

Wenn ein Apache-Server so betrieben wird, daß er die dynamische Einbindung von Modulen unterstützt (also das Modul mod_so verwendet), dann wird während der Apache-Installation in dessen bin-Verzeichnis ein Hilfsprogramm mit dem Namen apxs erzeugt.

Dieses Programm ermöglicht es seinem Anwender, den Programm-Quelltext eines Apache-Moduls (mit Hilfe eines C-Compilers) zu übersetzen und eine entsprechende shared-object-Datei zu erzeugen, ohne daß hierfür der komplette Quelltext des Apache-Servers vorhanden sein muß: apxs kennt alle erforderlichen Apache-Programmschnittstellen und versorgt den C-Compiler mit den entsprechenden Informationen.

Das Erzeugen eines shared object für mod_gzip mit Hilfe von make

Um dem Anwender zu ersparen, herauszufinden, wie mod_gzip tatsächlich mit Hilfe von apxs vollständig übersetzt und installiert werden muß, wird im Quelltext-Archiv eine Datei mit dem Namen Makefile mitgeliefert.

Die Verwendung dieses Makefiles reduziert das Installationsverfahren auf die folgenden Schritte:

  1. Den Inhalt der heruntergeladenen Quelltext-Archiv-Datei von mod_gzip in ein beliebiges (neues, temporäres) Verzeichnis entpacken und das aktuelle Verzeichnis dorthin positionieren.
  2. Den Pfadnamen des Programms apxs der eigenen Apache-Installation herausfinden.
  3. Die Übersetzung durchführen mit dem Kommando 
    make         APXS=ihr_apxs_pfadname
    Hierbei entsteht die shared-object-Datei mod_gzip.so im aktuellen Verzeichnis.
    (Dieser Schritt dieser Aufzählung darf auch entfallen, da er in diesem Falle im nachfolgenden Schritt enthalten ist.)
  4. Die Installation durchführen mit dem Kommando 
    make install APXS=ihr_apxs_pfadname
    Hierbei wird nicht nur die shared-object-Datei in das entsprechende Verzeichnis der Apache-Installation kopiert, sondern auch die Apache-Konfigurationsdatei httpd.conf automatisch um die entsprechenden Direktiven LoadModule und AddModule erweitert ... wer nicht gerne fremde Programme seine kostbaren Konfigurationsdateien umschreiben lassen will, sollte diesen letzten Schritt lieber manuell durchführen oder zumindestens vorher eine Sicherheitskopie der Apache-Konfiguration erstellen.

Neben diesen notwendigen Schritten unterstützt das Makefile noch die folgenden Kommandos (welche allerdings eher für Entwickler von Interesse sein dürften):

(Michael Schröpl, 2003-09-24)