WWW Server |
| Übersicht |
|
| Apache |
|
| Tux |
|
Tux ist ein von RedHat entwickelter, kernel-basierter Webserver. Gerade diese Kernelrealisierung erlaubt dem Server, angeforderte Seiten direkt aus dem Seitencache auf die Netzwerkschnittstelle zu schreiben, ohne die zwischen »Userspace« und »Kernelspace« sonst notwendigen Kopieroperationen tätigen zu müssen (dieses Verfahren ist als »Zero Copy« bekannt). Im Wesentlichen resultiert aus diesem eingesparten Transfer die deutlich erhöhte Geschwindigkeit gegenüber anderen Webservern, mit der Tux die Seiten ins Web entlässt.
Statische Webseiten kann Tux vollständig mit boardeigenen Mitteln behandelt, relativ problematisch ist die Verarbeitung dynamischer Inhalte, die ja bekanntlich mehr und mehr die Webseiten durchdringen. Tux versucht auch solche dynamischen Seiten in seinen Seitencache aufzunehmen. Hierzu erzeugt ein (i.d.R.) im Userspace laufendes Tux-Modul (solche Module liegen nicht jedem Paket bei; dafür eine ausführliche Anleitung, wie sie zu schreiben sind) ein Objekt, dass anstelle der Webseite in den Seitencache platziert wird. Werden dynamische Daten vom Server angefordert, liefert das Objekt eine Mischung aus dynamischen erzeugten Inhalten und bereits vorbereiteten statischen Objekten (nahezu jede dynamische Webseite beinhaltet statische Elemente, bspw. Bilder). Diese statischen Objekte profitieren wiederum vom Zero-Copy-Protokoll, sodass letztlich auch die Auslieferung dynamischer Seiten eine Beschleunigung erfährt.
Weiß Tux einmal nichts mit einer Seite anzufangen - weil bspw. kein entsprechendes Modul existiert - leitet er die Anforderung an einen »normalen« Webserver weiter (bspw. an den Apache).
Ab Version 2.4 enthalten die Kernel offiziell die Unterstützung für Tux. Die relevanten Optionen finden Sie unter »Netzwerkoptionen« und lauten:
Threaded LinUX application protocol accelarator layer (TUX)
External CGI module
extended TUX logging format
debug TUX
Bevor Sie an die Kernelerstellung gehen, lohnt ein Blick in /proc/config.gz (existiert nur bei entsprechend konfiguriertem Kernel), ob die notwendigen Fähigkeiten nicht schon im laufenden Kernel enthalten sind:
| user@sonne> zcat /proc/config.gz | grep CONFIG_HTTP |
Des Weiteren benötigen Sie das Paket Tux; für die aktuellen Distributionen sollten vorkompilierte Versionen verfügbar sein.
Vermutlich haben Sie bislang einen anderen Webserver eingesetzt, der seine Arbeit an Port 80 verrichtete. Da Tux's Fähigkeiten nicht allen denkbaren Anforderungen genügen, wird im der »alte« Webserver als Assistent zur Seite gestellt. Was Tux nicht kann, deligiert er fortan an den Gehilfen weiter.
Im Falle des Apache müssen Sie den Eintrag »Port 80« aus seiner Konfigurationsdatei »httpd.conf« ändern. Als Portnummer können Sie eine beliebige nicht genutzte Nummer verwenden, also bspw. »Port 8080«. Außerdem empfiehlt es sich, den Eintrag »Bindaddress *« aus selbiger Datei in »Bindaddress 127.0.0.1« zu modifizieren, um direkten Verbindungen am Port 8080 von anderen Rechnern aus vorzubeugen.
RedHat /etc/sysconfig/tux SuSE /etc/rc.config.d/tux.rc.config
|
user@sonne> cat /etc/rc.config.d/tux.rc.config # /etc/sysconfig/tux # TUXTHREADS sets the number of kernel threads (and associated daemon # threads) that will be used. $TUXTHREADS defaults to the number of # CPUs on the system. # TUXTHREADS=1 # DOCROOT is the document root; it works the same way as other web # servers such as apache. /var/www/html/ is the default. #DOCROOT=/var/www/html/ DOCROOT=/usr/local/httpd/htdocs/ # CGI_UID and CGI_GID are the user and group as which to run CGIs. # They default to "nobody" # CGI_UID=nobody CGI_GID=nogroup # DAEMON_UID and DAEMON_GID are the user and group as which the daemon runs # They default to "nobody" # This does not mean that you should execute untrusted modules -- they # are opened as user/group root, which means that the _init() function, # if it exists, is run as root. This feature is only designed to help # protect from programming mistakes; it is NOT really a security mechanism. # DAEMON_UID=nobody DAEMON_GID=nogroup # CGIs can be started in a chroot environment by default. # Defaults to $DOCROOT; set CGIROOT=/ if you want CGI programs # to have access to the whole system. # CGIROOT=/var/www/html # each HTTP connection has an individual timer that makes sure # no connection hangs forever. (due to browser bugs or DoS attacks.) # MAX_KEEPALIVE_TIMEOUT=30 # TUXMODULES is a list of user-space TUX modules. User-space TUX # modules are used to serve dynamically-generated data via tux. # "man 2 tux" for more information # TUXMODULES="demo.tux demo2.tux demo3.tux demo4.tux" # MODULEPATH is the path to user-space TUXapi modules # MODULEPATH="/" |
Um Problemen auf die Schliche zu kommen, empfiehlt sich in einer zweiten Konsole die Datei /var/log/messages zu überwachen. Meldungen wie
|
root@sonne> tail -f /var/log/messages ... Sep 3 18:29:25 feld kernel: TUX: could not look up documentroot: "/var/www/html/" ... Sep 3 18:34:45 feld kernel: TUX: error -98 binding socket. This means that probably some other process is (or was a short time ago) using addr 00000000, port 80. Sep 3 18:34:45 feld kernel: TUX: could not start worker thread 0. |
fokussieren die Fehlerquelle ziemlich exakt. Im ersten Fall versucht Tux von einer nicht existierenden - oder mit falschen Rechten versehenen - Dokumenten-Root zu lesen ("/var/www/html/" sollte bei RedHat-basierten Distributionen der richtige Eintrag sein; bei SuSE ist es "/usr/local/httpd/htdocs/"). Die zweite Meldung resultiert aus einem Programm, das bereits den Port 80 belegt hat. Vermutlich wurde der Apache zuvor gestartet, obwohl Tux zwingend vor diesem den Port belegen muss.
| user@sonne> lynx -head -dump http://127.0.0.1/ HTTP/1.1 200 OK Content-Type: text/html Date: Mon, 03 Sep 2001 16:36:48 GMT Server: TUX/2.0 (Linux) Content-Length: 55 |
| Kernel-Httpd |
|