Seit Jahren erwartet, ist endlich Version 4 des Samba-Servers erschienen, der nun als vollwertige Alternative zu Microsofts Active Directory dienen kann. In der ... (mehr)

Virtuelle Hosts

Wie die Bearbeitung von HTTP-Anfragen erfolgen soll, legt der Block »http« fest. Wie alle modernen Webserver kann auch Tengine auf einem physischen Server mehrere unabhängige Internetauftritte verwalten. Abhängig von der aufgerufenen Domain liefert Tengine dann die passenden Seiten aus. Es entstehen so virtuelle Server, für die im »http« -Block jeweils ein eigener »server« -Block existiert. In Listing 1 gibt es nur einen (virtuellen) Server namens »localhost« , der an Port 80 lauscht.

Die im »location« -Block gesammelten Einstellungen gelten nur für die angegebenen URIs. Aufgrund des Schrägstrichs »/« gelten in Listing 1 die beiden Einstellungen für alle Anfragen. Diese Einstellungen legen wiederum fest, dass alle zum Webauftritt gehörenden Dateien im Unterverzeichnis »html« des Tengine-Verzeichnisses liegen ( »root html« ) und die Index-Datei »index.html« oder »index.htm« heißt. Es dürfen übrigens mehrere »location« -Blöcke für einen Server existieren, Unterseiten kann Tengine folglich unterschiedlich behandeln.

Wenn ein Fehler mit der Nummer 500, 502, 503 oder 504 auftritt, leitet Tengine gemäß Listing 1 die Anfrage zur URL »/50x.html« weiter. Dies bestimmt die Einstellung »error_page« . Das nachfolgende »location« verrät schließlich noch, dass die entsprechende Fehlerseite ebenfalls im Verzeichnis »html« schlummert.

Alle noch nicht angesprochenen Einstellungen im oberen Bereich des »http« -Blocks wirken sich auf alle virtuellen Server aus. »include« bindet zunächst eine weitere Konfigurationsdatei ein. In diesem Fall enthält sie einfach eine Liste, die ein paar Dateiendungen ihren jeweiligen MIME-Typen zuordnet (genauer gesagt, enthält die Datei »mime.types« den Block »types« ). Kann Tengine später für eine Datei dennoch keinen MIME-Typ ermitteln, verwendet es standardmäßig ( »default_type« ) den MIME-Typ »application/octet-stream« .

Sogenannte Keep-Alive-Verbindungen [6] setzt der Webserver nach 65 Sekunden zurück ( »keepalive_timeout 65« ). Damit Dateien schneller von der Festplatte in den Hauptspeicher wandern, nutzt Tengine schließlich noch die »sendfile« -Funktion des (Linux-)Kernels [7] .

Wie Nginx fasst Tengine seine Funktionen in einzelnen Modulen zusammen. Nginx linkt jedoch alle aktivierten Module direkt in die Programmdatei. Benötigt man nachträglich weitere Funktionen, muss man folglich den Webserver komplett neu erstellen. In Tengine darf man immerhin einige der Module in dynamisch gelinkte Bibliotheken auslagern (die Dynamic Shared Objects, kurz DSOs). Diese kann man dann nachträglich an den Webserver anschrauben.

Um ein Modul in ein DSO zu verwandeln, wechselt man in das Quellcodeverzeichnis von Tengine. Dort startet man erneut »configure« mit dem Parameter, der das Modul aktiviert, hängt diesem Parameter aber noch ein »=shared« an. Das für die Lua-Anbindung zuständige Modul presst beispielsweise »./configure --with-http_lua_module=shared« in ein DSO. Das Lua-Modul setzt übrigens einen bereits installierten Lua-Interpreter mitsamt seinen Entwicklungsdateien voraus.

Dynamische Module

Abschließend muss man nur noch einmal »make« anwerfen und dann per »make dso_install« das fertige DSO in das dafür vorgesehene Verzeichnis kopieren lassen. Letztgenanntes lautet standardmäßig »/usr/local/nginx/modules/« . Um ein anderes Verzeichnis zu wählen, muss man dies »configure« über den Parameter »--dso-path=« mitteilen – und zwar sowohl bereits bei der Erstellung von Tengine als auch beim Übersetzen der DSOs.

Derzeit kann Tengine maximal 128 DSOs gleichzeitig jonglieren. Darüber hinaus lassen sich nur ein paar HTTP-Module in DSOs verwandeln. Welche das im Einzelnen sind, verrät »./configure --help« . In der Ausgabe sind einige – aber leider nicht alle – DSO-fähigen Module mit »(shared)« markiert. Als Faustregel gilt, dass man mit »--with-http...« beginnende Module in ein DSO pressen kann.

Um ein DSO-Modul zu laden, fügt man außerhalb aller anderen Blöcke einen neuen namens »dso« hinzu. In ihm führt man dann die zu ladenden Module auf. Listing 2 zeigt exemplarisch, wie man auf diese Weise das Lua-Modul lädt.

Listing 2

Laden eines DSO-Moduls

 

Nachdem man die Konfigurationsdatei verändert hat, hält man Tengine an: »sudo /usr/local/nginx/sbin/nginx -s stop« und startet es neu: »sudo /usr/local/nginx/sbin/nginx« . Alle derzeit geladenen Module verrät »sudo /usr/local/nginx/sbin/nginx -m« . Ein »(static)« weist daraufhin, dass das Modul fest in Tengine einkompiliert ist (wie in Abbildung 1 ). Die Unterstützung von DSOs kann man bei der Erstellung von Tengine auch komplett über den Parameter »--without-dso« abschalten (der Parameter weist übrigens dezent daraufhin, dass die DSOs ein eigenes Modul namens »ngx_dso_module« verwaltet).

Abbildung 1: Alle von Tengine genutzten Speicherorte präsentiert configure noch einmal übersichtlich am Ende seines Durchlaufs.
comments powered by Disqus
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Konfigurationsmanagement

Ich konfiguriere meine Server

  • von Hand
  • mit eigenen Skripts
  • mit Puppet
  • mit Ansible
  • mit Saltstack
  • mit Chef
  • mit CFengine
  • mit dem Nix-System
  • mit Containern
  • mit anderer Konfigurationsmanagement-Software

Ausgabe /2023