[[Vorlage(Getestet, hardy, lucid, oneiric, precise, quantal)]] {{{#!vorlage Wissen [:Pakete_installieren: Installation von Programmen] [:Paketquellen_freischalten/PPA: Verwenden eines PPAs] (''optional'') [:Packprogramme: Archive entpacken] (''optional'') [:Programme kompilieren: Pakete aus dem Quellcode erstellen] (''optional'') [:Terminal: Ein Terminal öffnen] [:Editor: Einen Editor öffnen] }}} [[Inhaltsverzeichnis(1)]] [[Bild(nginx-logo.png, 100, left)]] [http://www.nginx.org nginx] {en} (gesprochen „engine x”) ist ein Webserver, welcher gegenüber [:Apache:] sehr schnell und schmal ist. Er ist dafür ausgelegt, selbst unter hoher Last nur wenig Ressourcen zu verbrauchen. nginx wurde von Igor Sysoev entwickelt und wird [http://news.netcraft.com/archives/2013/03/01/march-2013-web-server-survey.html laut netcraft] {en} von 13.5% (Stand: März 2013) aller Websites genutzt. = Installation = [[Bild(Startseite/Software.png, align=right)]] Ab [:Hardy:Ubuntu Hardy 8.04] kann nginx aus den offiziellen Paketquellen installiert werden [1]: {{{#!vorlage Paketinstallation nginx, universe }}} == PPA == Eine – je nach eingesetzter Ubuntu-Version – aktuellere nginx-Version ist über ein "Personal Package Archiv" (PPA) [2] erhältlich. [[Vorlage(PPA, nginx, stable)]] == Manuell == Zuerst muss der Quellcode von [http://nginx.org/en/download.html nginx.org] {dl} heruntergeladen werden. Bevor nginx kompiliert werden kann, benötigt es folgende Pakete: {{{#!vorlage Paketinstallation gcc libevent build-essential }}} Nun entpackt [3] man das Paket und kompiliert [4] nginx. Damit sich das selbst-kompilierte nginx (fast) wie eine Paket-Installation anfühlt, setzt man noch folgende symbolischen Links: {{{ mkdir /etc/nginx ln -s /usr/local/nginx/conf/nginx.conf /etc/nginx/nginx.conf ln -s /usr/local/nginx/sbin/nginx /usr/local/bin/nginx }}} Somit spart man sich das umständliche Zusammensuchen der Komponenten und kann nginx direkt ohne Pfadangabe starten. = Konfiguration = [[Bild(Wiki/Icons/settings.png,64, align=right)]] nginx liest die Konfiguration aus der Datei '''/etc/nginx/nginx.conf'''. Diese besteht aus den Blöcken `events { [...] }` und `http { [...] }`. Kommentiert wird mit einer Raute (`#`). == Konfigurieren des Webservers == [[Bild(Wiki/Icons/internet.png,64,align=right)]] === Grundkonfiguration === Damit nginx an eine Domain oder IP gebunden wird, muss folgender Grundblock in den '''http'''-Teil eingefügt werden: {{{ server { } }}} {{{#!vorlage Hinweis Die Datei ist nach der Installation schon vorkonfiguriert. Es ist empfehlenswert, jegliche ``server { [...] }``-Bereiche zu entfernen, um Komplikationen zu vermeiden. }}} Nun wird angegeben, an welchen Port sich nginx binden soll (`80`) und an welche Domain bzw. IP (`localhost`): {{{ server { listen 80; server_name localhost; } }}} [[Anker(rootverzeichnis)]] Alleine mit dieser Konfiguration ist nginx bereits erreichbar, hat aber keine Daten verfügbar, die an den Benutzer versendet werden können. Dies ändert man mit ``root`` (im Beispiel liegen die Dateien in '''/srv/localhost'''): {{{ root /srv/localhost; }}} {{{#!vorlage Hinweis ``root`` steht für ``document root`` und nicht, wie man denken könnte, für den Benutzer ``root``. }}} Zuletzt wird noch festgelegt, welche Datei aufgerufen werden soll, wenn der Nutzer nur ``localhost`` eintippt: {{{ location / { index index.html index.htm; } }}} === Domains einbinden === Domains lassen sich folgendermaßen einbinden: {{{ server_name www.example.com example.com; }}} Damit hört nginx sowohl an ``www.example.com`` als auch ``example.com``. === Sub- und Wildcarddomains einbinden === Sub- und Wildcarddomains bindet man mit {{{ server_name *.example.com subdomain.example.com; }}} ein. {{{#!vorlage Warnung Jede Domain, die in ``server_name`` aufgelistet ist, wird auch von dem (virtuellen) Server betrieben. Konkret würde dies für das Beispiel heißen, dass die beiden Domains mit dem gleichen Inhalt und den gleichen Einstellungen betrieben werden. }}} === Beispiel === {{{ [...] http { server { listen 80; server_name localhost example.com www.example.com; root /srv/daten; location / { index index.html index.htm; } } server { listen 80; server_name subdomain.example.com; root /srv/subdomain/daten; location / { index index.html index.htm; } } } [...] }}} == Ändern der Umgebung == === Ändern des Nutzers === nginx kann - wie viele andere Webserver - auch einen anderen Nutzer als „root” benutzen. Um dies auszulösen, ändert man folgende Zeile: {{{ #user nobody; }}} ab zu folgender Zeile (in diesem Beispiel wird der Nutzer „www-data” verwendet): {{{ user www-data; }}} Dies ändert - unabhängig davon, mit welchem Nutzer nginx gestartet wurde - das Konto, mit dem der [wikipedia:Daemon:] arbeitet. === Aktivierung einer Logdatei === Um eine komplette Logdatei nach '''/etc/nginx/logs/error.log''' zu schreiben, ändert man die Zeile: {{{ #error_log logs/error.log; }}} ab zu: {{{ error_log /etc/nginx/logs/error.log; }}} Durch das Hinzufügen von `info` oder `notice` nach dem Dateinamen kann das Protokoll gefiltert werden. Dies bedeutet, dass z.B. nur Informationen gesichert werden. = Steuerung von nginx = nginx bildet sich aus einem „Master”-Prozess und vielen „Slave”- bzw. „Client”-Prozessen. Man steuert nginx mit dem Master-Prozess, den man mit dem Befehl `nginx` anspricht. Dies geht nach folgendem Prinzip: {{{#!vorlage Befehl nginx [-s signal] [-c filename] [-p prefix] [-g directives] }}} == Mögliche Befehle == Starten lässt sich nginx recht simpel: {{{#!vorlage Befehl sudo nginx }}} Es sind [:sudo:Rootrechte] erforderlich, wenn nginx an einem Port kleiner als `1024` horchen soll (siehe auch [wikipedia:Liste der standardisierten Ports:]). Für das Stoppen übergibt man das "stop"-Signal an nginx: {{{#!vorlage Befehl sudo nginx -s stop }}} Falls ein [:Dienste:]-Skript vorhanden ist, kann man nginx auch mit diesen Optionen steuern: {{{#!vorlage Befehl /etc/init.d/nginx (start|stop|restart|reload|force-reload) }}} == Andere Konfigurationsdatei verwenden == Falls eine andere Konfigurationsdatei als '''/etc/nginx/nginx.conf''', z.B. zu Testzwecken, verwendet werden soll, startet man nginx folgendermaßen: {{{#!vorlage Befehl sudo nginx -c /pfad/der/konfigurationsdatei }}} = Optimierung von nginx = == GZip-Komprimierung aktivieren == Dank der GZip-Komprimierung kann man sich viel Datenverkehr sparen. Wie die Kompression von Websites funktioniert und warum man sie aktivieren sollte, kann man auf [http://betterexplained.com/articles/how-to-optimize-your-site-with-gzip-compression/ betterexplained.com] {en} nachlesen. nginx kann alle Typen von Websites und Textdateien komprimieren, im Gegensatz zu dem ZLib-Modul von PHP, welches nur PHP komprimiert. Um die Komprimierung zu aktivieren, fügt man folgende Zeile in den ``http { [...] }``-Block ein: {{{ gzip on; }}} und startet nginx neu. Zusätzlich sollte man festlegen, welche Dateitypen geschrumpft werden sollen und welche Browser ausgenommen werden sollen: {{{ gzip_types text/plain application/xml; gzip_disable "MSIE [1-6]\."; }}} == Charset festlegen == Falls ein Charset (=Zeichensatz) festgelegt werden soll, kann man sich mit folgendem Befehl im ``server { [...] }``-Block behelfen: {{{ charset utf-8; }}} = PHP mit nginx = [[Bild(php-logo.png, align=right)]] nginx verlangt für PHP eine FastCGI-Schnittstelle. Da PHP nicht im Passiv-Modus agiert, müssen - wie für FastCGI üblich - PHP-Instanzen gestartet werden, die im Arbeitsspeicher auf ihren Einsatz warten. Zuerst installiert man PHP im CGI-Modus, falls noch nicht geschehen, mit folgendem Paket: {{{#!vorlage Paketinstallation php5-cgi }}} == Ab Ubuntu Hardy 8.04 == Bis Ubuntu 9.10 existiert das Paket '''spawn-fcgi''' nicht, mit welchem man sonst die Instanzen hätte einfacher starten können, weswegen man einen "start-stop-daemon" verwenden muss. Dazu erstellt man die Datei '''/usr/bin/php-fastcgi''' und füllt sie mit folgendem [:Bash:]-Skript: {{{#!code bash #!/bin/bash BIND=127.0.0.1:9000 USER=www PHP_FCGI_CHILDREN=4 PHP_FCGI_MAX_REQUESTS=1000 PHP_CGI=/usr/bin/php-cgi PHP_CGI_NAME=`basename $PHP_CGI` PHP_CGI_ARGS="- USER=$USER PATH=/usr/local/bin PHP_FCGI_CHILDREN=$PHP_FCGI_CHILDREN PHP_FCGI_MAX_REQUESTS=$PHP_FCGI_MAX_REQUESTS $PHP_CGI -b $BIND" RETVAL=0 start() { echo -n "Startet PHP FastCGI: " start-stop-daemon --quiet --start --background --chuid "$USER" --exec /usr/bin/env -- $PHP_CGI_ARGS RETVAL=$? echo "$PHP_CGI_NAME." } stop() { echo -n "Stoppt PHP FastCGI: " killall -q -w -u $USER $PHP_CGI RETVAL=$? echo "$PHP_CGI_NAME." } case "$1" in start) start ;; stop) stop ;; restart) stop start ;; *) echo "Benutzung: php-fastcgi {start|stop|restart}" exit 1 ;; esac }}} Zuerst gilt es nun zu überprüfen, ob die Datei in Zeile 7 überhaupt existiert. Falls nicht, ändert man den Pfad passend ab. Danach ändert man in Zeile 3 den Benutzer, mit dem die FastCGI-Instanzen laufen sollen und zu guter Letzt muss das Skript ausführbar gemacht werden: {{{#!vorlage Befehl chmod a+x /usr/bin/php-fastcgi }}} Man startet die Instanzen nun mit dem Befehl {{{#!vorlage Befehl sudo php-fastcgi start }}} == Ab Ubuntu Karmic 9.10 == Zuerst installiert man, falls noch nicht geschehen, das Paket {{{#!vorlage Paketinstallation spawn-fcgi,universe }}} Dann erstellt man ein [:Bash:]-Skript, welches die Instanzen startet (Quelle: [http://library.linode.com/web-servers/nginx/php-fastcgi/ubuntu-9.10-karmic Linode.com - Nginx and PHP-FastCGI on Ubuntu] {en} ): {{{#!code bash #!/bin/sh /usr/bin/spawn-fcgi -a 127.0.0.1 -p 9000 -u www-data -f /usr/bin/php5-cgi }}} Das Skript speichert man unter '''/usr/bin/php-fastcgi''' ab und setzt mit {{{#!vorlage Befehl chmod a+x /usr/bin/php-fastcgi }}} die richtigen Rechte. Man startet nun die Instanzen mit dem Befehl {{{#!vorlage Befehl sudo php-fastcgi }}} == Universelle Methode == Falls es Probleme geben sollte, kann man versuchen, PHP direkt an eine FastCGI-Schnittstelle zu binden. Dafür legt man die Datei '''/usr/bin/php-fastcgi''' mit folgendem Inhalt an: {{{#!code bash #!/bin/bash php-cgi -b 127.0.0.1:9000 }}} Danach vergibt man Ausführrechte: {{{#!vorlage Befehl chmod a+x /usr/bin/php-fastcgi }}} Und zu guter Letzt startet man die FastCGI-Schnittstelle mit dem Befehl: {{{#!vorlage Befehl sudo php-fastcgi }}} == Die Konfiguration von nginx anpassen == Zu guter Letzt muss jetzt nur noch nginx wissen, wie man sich an die Schnittstelle bindet. Dazu fügt man in den ``server { [...] }``-Block folgendes ein: {{{ location ~ \.php$ { fastcgi_pass localhost:9000; include fastcgi.conf; } }}} = Python mit nginx = [[Bild(python-logo.gif,align=right)]] [[Vorlage(Ausbaufähig, "uWSGI und nginx harmonieren deutlich besser.")]] == proxy_pass mit Django/Werkzeug == Rechnet man mit einem nicht so großen Ansturm und möchte Djangos kleinen Entwicklungs-Webserver starten, geht man wie folgt vor: Zuerst startet man den Webserver wie gewohnt: {{{#!vorlage Befehl python manage.py runserver }}} oder {{{#!vorlage Befehl nohup python manage.py runserver & # So läuft der Server im Hintergrund }}} Alternativ kann man auch jeden anderen Webserver starten, wie z.B. auch ein Skript mit [http://werkzeug.pocoo.org/ Werkzeug] {en} ausgestattet (im Beispiel wird dabei von Port 8000 ausgegangen). Folgenden `location`-Block benötigt man für diese Methode: {{{ location / { proxy_pass http://127.0.0.1:8000; } }}} Damit werden alle Anfragen an diese `location` an `http://127.0.0.1:8000` weitergeleitet. {{{#!vorlage Hinweis Trotz der Weiterleitung übergibt nginx den angesteuerten Pfad (z.B. `http://example.com/neu/`, und nicht `http://127.0.0.1:8000/neu/`). }}} == FastCGI-Schnittstelle mit Django == In diesem Beispiel wird Django als FastCGI-Schnittstelle verwendet, um z.B. mit vielen Anfragen umzugehen. Dafür wird aber eine kleine Veränderung in der Konfiguration benötigt: {{{ server { listen 80; server_name localhost; location / { fastcgi_pass 127.0.0.1:9000; fastcgi_param PATH_INFO $fastcgi_script_name; fastcgi_param REQUEST_METHOD $request_method; fastcgi_param QUERY_STRING $query_string; fastcgi_param CONTENT_TYPE $content_type; fastcgi_param CONTENT_LENGTH $content_length; fastcgi_pass_header Authorization; fastcgi_intercept_errors off; include fastcgi_params; } } }}} Außerdem benötigt Django für die FastCGI-Schnittstelle Flup. Dieses kann [http://www.saddi.com/software/flup/ hier] {en} heruntergeladen werden oder mit easy_install (s. [:Python Setuptools:]) installiert werden: {{{#!vorlage Befehl sudo easy_install flup }}} Zuletzt muss nur noch Django gestartet werden: {{{#!vorlage Befehl python manage.py runfcgi host=127.0.0.1 port=9000 --settings=settings }}} = Perl mit nginx = [[Bild(camel_head.png,align=right)]] Um Perl zum Laufen zu bekommen, ist einige Arbeit nötig: Zuerst einmal muss Perl überhaupt eine FastCGI-Schnittstelle bekommen. Das geht mit dem Befehl {{{#!vorlage Befehl perl -MCPAN -e 'install FCGI' }}} Dann muss ein Perl-Skript geschrieben werden, über das Perl abläuft ([http://www.ruby-forum.com/topic/145858 Quelle] {en}) : {{{#!code perl #!/usr/bin/perl use FCGI; use Socket; use POSIX qw(setsid); require 'syscall.ph'; &daemonize; #this keeps the program alive or something after exec'ing perl scripts END() { } BEGIN() { } *CORE::GLOBAL::exit = sub { die "fakeexit\nrc=".shift()."\n"; }; eval q{exit}; if ($@) { exit unless $@ =~ /^fakeexit/; }; &main; sub daemonize() { chdir '/' or die "Can't chdir to /: $!"; defined(my $pid = fork) or die "Can't fork: $!"; exit if $pid; setsid or die "Can't start a new session: $!"; umask 0; } sub main { $socket = FCGI::OpenSocket( "127.0.0.1:9000", 10 ); #use IP sockets $request = FCGI::Request( \*STDIN, \*STDOUT, \*STDERR, \%req_params, $socket ); if ($request) { request_loop()}; FCGI::CloseSocket( $socket ); } sub request_loop { while( $request->Accept() >= 0 ) { #processing any STDIN input from WebServer (for CGI-POST actions) $stdin_passthrough =''; $req_len = 0 + $req_params{'CONTENT_LENGTH'}; if (($req_params{'REQUEST_METHOD'} eq 'POST') && ($req_len != 0) ){ my $bytes_read = 0; while ($bytes_read < $req_len) { my $data = ''; my $bytes = read(STDIN, $data, ($req_len - $bytes_read)); last if ($bytes == 0 || !defined($bytes)); $stdin_passthrough .= $data; $bytes_read += $bytes; } } #running the cgi app if ( (-x $req_params{SCRIPT_FILENAME}) && #can I execute this? (-s $req_params{SCRIPT_FILENAME}) && #Is this file empty? (-r $req_params{SCRIPT_FILENAME}) #can I read this file? ){ pipe(CHILD_RD, PARENT_WR); my $pid = open(KID_TO_READ, "-|"); unless(defined($pid)) { print("Content-type: text/plain\r\n\r\n"); print "Error: CGI app returned no output - "; print "Executing $req_params{SCRIPT_FILENAME} failed !\n"; next; } if ($pid > 0) { close(CHILD_RD); print PARENT_WR $stdin_passthrough; close(PARENT_WR); while(my $s = ) { print $s; } close KID_TO_READ; waitpid($pid, 0); } else { foreach $key ( keys %req_params){ $ENV{$key} = $req_params{$key}; } # cd to the script's local directory if ($req_params{SCRIPT_FILENAME} =~ /^(.*)\/[^\/]+$/) { chdir $1; } close(PARENT_WR); close(STDIN); #fcntl(CHILD_RD, F_DUPFD, 0); syscall(&SYS_dup2, fileno(CHILD_RD), 0); #open(STDIN, "<&CHILD_RD"); exec($req_params{SCRIPT_FILENAME}); die("exec failed"); } } else { print("Content-type: text/plain\r\n\r\n"); print "Error: No such CGI app - $req_params{SCRIPT_FILENAME} may not "; print "exist or is not executable by this process.\n"; } } } }}} Gespeichert wird das Perl-Skript unter '''/usr/bin/fastcgi-wrapper.pl'''. Die Schreibrechte müssen auch korrekt gesetzt werden: {{{#!vorlage Befehl chmod a+x /usr/bin/fastcgi-wrapper.pl }}} Zusätzlich wird noch ein Startskript erstellt, welches unter '''/usr/bin/perl-fastcgi''' gespeichert wird ([http://library.linode.com/web-servers/nginx/perl-fastcgi/ubuntu-9.10-karmic Quelle] {en}) : {{{#!code bash #!/bin/bash PERL_SCRIPT=/usr/bin/fastcgi-wrapper.pl RETVAL=0 case "$1" in start) $PERL_SCRIPT RETVAL=$? ;; stop) killall -9 perl RETVAL=$? ;; restart) killall -9 perl $PERL_SCRIPT RETVAL=$? ;; *) echo "Usage: perl-fastcgi {start|stop|restart}" exit 1 ;; esac exit $RETVAL }}} Auch dieses Skript wird ausführbar gemacht: {{{#!vorlage Befehl chmod a+x /usr/bin/perl-fastcgi }}} Man startet nun die Schnittstelle mit {{{#!vorlage Befehl perl-fastcgi start }}} Zuletzt muss nur noch die nginx-Konfiguration angepasst werden: {{{ location ~ \.pl$ { include fastcgi.conf; fastcgi_pass 127.0.0.1:9000; } }}} {{{#!vorlage Hinweis GZip-Komprimierung verlangsamt die Skripte. }}} = Module = nginx besitzt standardmäßig nur einige Module, welche [http://wiki.nginx.org/NginxModules#Standard_HTTP_Modules hier] {en} gelistet sind. Allerdings kann man nginx mit vielen weiteren Modulen benutzen, deren offiziellen Anlaufstellen [http://wiki.nginx.org/NginxModules#Optional_HTTP_modules hier] {en} und [http://wiki.nginx.org/Nginx3rdPartyModules hier] {en} sind. Die Module kann man allerdings - nicht wie bei allen anderen Webservern - direkt benutzen, sondern muss sie mit nginx kompilieren[4]. Wie das funktioniert, steht in aller Regel in der Dokumentation des Modules. Bei optionalen HTTP-Modulen ([http://wiki.nginx.org/NginxModules#Optional_HTTP_modules hier] gelistet) funktioniert das folgendermaßen: Im Beispiel wird '''SSL'''-Unterstützung installiert. Man bezieht sich den Quellcode (siehe '''Installation''') von nginx und entpackt ihn. Statt nun {{{#!vorlage Befehl ./configure }}} einzutippen, fügt man nun das Modul an: {{{#!vorlage Befehl ./configure --with-http_ssl_module }}} Somit wird bei der weiteren Kompilierung SSL berücksichtigt. Um SSL zu benutzen, muss die Konfiguration angepasst werden, wie es im [http://wiki.nginx.org/NginxHttpSslModule nginx-Wiki] {en} beschrieben wird. = Tipps & Tricks = == IPv6 == Um nginx für [wikipedia:IPv6:] bereit zu machen, muss man zuerst - sofern man den Webserver nicht als Paket installiert hat - folgendermaßen neu kompilieren: {{{#!vorlage Befehl ./configure --with-ipv6 make sudo make install }}} Im zweiten Schritt öffnet man die Konfigurationsdatei und sorgt dafür, dass nginx IPv4- und IPv6-Verbindungen an Port 80 akzeptiert, indem man `listen 80` durch `listen [::]:80` ersetzt. Sofern noch nicht erledigt, müssen für jede Domain AAAA-Einträge in seinem DNS-Manager angelegt sein. == Loadbalancing mit nginx == [wikipedia:Loadbalancing:] ist standardmäßig in nginx vorhanden und schlägt laut [http://www.admin-blog.com/archives/227-Nginx-vs-Pound-Klarer-Sieg-fuer-Nginx-als-Loadbalancer.html diesem Artikel] {de} [wikipedia:Pound_(Software):Pound] deutlich. Im folgenden Beispiel verteilt nginx die Last auf 3 Server: {{{ http { upstream loadbalancer { server 127.0.0.1:8000; server 127.0.0.1:8001; server 127.0.0.1:8002; } server { listen 80; server_name www.example.com example.com; location / { proxy_pass http://loadbalancer; } } } }}} Zur Erklärung: Im Upstream ``loadbalancer`` sind drei (Web-)Server vorhanden und mit ihren jeweiligen Daten (``IP:Port``) angegeben. Im ``server { [...] }``-Block hört nginx an den Domains ``www.example.com`` und ``example.com`` an Port 80 und leitet die Anfrage an den upstream weiter. == Rewriting == nginx unterstützt URL-Rewriting nativ und kann mithilfe von Regex ([wikipedia:Regulärer Ausdruck:]) Anfragen umschreiben. So kann zum Beispiel eine Domain `example.com/artikel.php?id=123` zu `example.com/artikel/123` vereinfacht werden, ohne dass der Nutzer weitergeleitet werden muss. Das Rewriting kann im Hintergrund auf Server-Ebene geschehen. Um Rewriting zu aktivieren, fügt man folgendes in seine Konfiguration in einem ``server { [...] }``-Block ein: {{{ rewrite ^/artikel/(.*)$ /artikel.php?id=$1? last; }}} Der reguläre Ausdruck ``^/artikel/(.*)$`` bedeutet folgendes: Existiert in der aufgerufenen Domain an irgendeiner Stelle die Zeichenfolge `/artikel/` wird sämtliches hinter dieser an `artikel.php` als GET-Parameter `id` übergeben. Dieses Rewriting passiert mit der Flag `last` nur intern. nginx bietet folgende Flags zur Auswahl an: {{{#!vorlage Tabelle last/break Internes Rewriting ohne Weiterleitung +++ redirect Leitet den Nutzer auf die Seite weiter (HTTP 302 - Temporäre Weiterleitung) +++ permanent Leitet den Nutzer auf die Seite weiter (HTTP 301 - Dauerhafte Weiterleitung) }}} {{{#!vorlage Warnung Ohne eine gesetzte Flag gibt nginx den Fehler HTTP 500 zurück. }}} Weitere Hilfe, Tipps und Tricks findet man im [http://wiki.nginx.org/HttpRewriteModule nginx-Wiki] {en}. = Absicherung von nginx = Man stelle sich vor, ein Hacker würde eine Datei via PHP/Perl/Python in das Verzeichnis '''/uploads/''' hochladen. Diese Datei ist mit Schadcode infiziert und würde bei der Ausführung dem Server schaden. Wenn jetzt aber die Ausführung der Datei nicht verboten wird, könnte der Hacker seinen Angriff starten. Um das zu verhindern, fügt man in den ``server { [...] }``-Block folgendes ein: {{{ if ($uri !~ "^/uploads/") { fastcgi_pass 127.0.0.1:9000; } }}} Dies löst aus, dass alle Dateien, die sonst über die FastCGI-Schnittstelle an Port 9000 laufen würden, in allen Ordnern mit dem Namen '''uploads''' nicht mehr ausgeführt werden. = Erste Hilfe bei Problemen = [[Bild(Wiki/Icons/hint.png, 64, align=right)]] Siehe auch [http://wiki.nginx.org/Pitfalls Nginx Pitfalls] {en} (sinngemäß: typische Fehler). == Bei allen PHP-Dateien wird nur "No input file specified" angezeigt == Dies ist ein üblicher Fehler, der aber schnell behoben werden kann. Es gibt zwei hauptsächliche Ursachen: === Ursache 1 === Folgende Konfiguration wird für PHP-Dateien benutzt: {{{ location ~ \.php$ { fastcgi_pass localhost:9000; include fastcgi_params; # Statt fastcgi.conf } }}} Da nur in der Datei '''fastcgi.conf''' spezifiziert ist, dass PHP-Dateien auch unabhängig von dem `document root`-Verzeichnis verarbeitet werden sollen, sollte man diese statt '''fastcgi_params''' verwenden. Wer '''fastcgi_params''' trotzdem nutzen möchte, kann statt des Ersetzen folgende Zeile hinzufügen: {{{ fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; }}} === Ursache 2 === Folgende (vereinfachte) Konfiguration wird benutzt: {{{ location / { root /srv/www/; } location ~ \.php$ { fastcgi_pass localhost:9000; include fastcgi.conf; } }}} Da die location `~ \.php$` eine andere als `/` ist, ist für die FastCGI-Schnittstelle unbekannt, wo das Wurzelverzeichnis für diesen `server { [...] }`-Block ist, weil dieses nur in `location /` festgelegt ist. Folgende Konfiguration löst dieses Problem: {{{ root /srv/www/; # 'root' wird nun global für den server { [...] }-Block festgelegt location ~ \.php$ { fastcgi_pass localhost:9000; include fastcgi.conf; } }}} == nginx zeigt bei existierenden Dateien im Browser "403" an == Benutzerberechtigungen überprüfen! Diese Meldung kommt meistens, wenn nginx bzw. der Benutzer, mit dem nginx läuft, keinen Zugriff auf die Dateien hat. == Es erscheint auf allen Websites nur noch die Meldung "502 Bad Gateway" == Dies passiert, wenn die FastCGI-Schnittstelle oder die Adresse von `proxy_pass` nicht für nginx erreichbar ist (auf Servern kann dies mit [:Lynx:] überprüft werden). Gründe können z.B. ein Absturz der Schnittstelle sein. Da man das Problem mithilfe dieser Meldung nicht pauschal festmachen kann, gibt es [http://www.codeweblog.com/nginx-502-bad-gateway-error-collection-problem/ hier] {en} eine Liste von möglichen Ursachen und deren Behebung. == nginx verarbeitet keine .htaccess-Dateien == Das ist korrekt, da alle Änderungen bzw. Einstellungen in der Konfigurationsdatei '''nginx.conf''' vorgenommen werden. Und Absicht - div. Gründe, wieso es unter nginx keine htaccess-Dateien gibt, finden sich im [http://wiki.nginx.org/LikeApache-htaccess FAQ von nginx] {en} - kurz gesagt ist '''.htaccess''' ist ein Performancekiller und potentielle Sicherheitslücke. Allerdings gibt es diverse [http://winginx.com/htaccess Konverter] {en} von htaccess zu nginx, um den Umstieg leicht zu machen. == nginx startet nicht automatisch == Eventuell fehlt das '''/etc/init.d/'''-Startskript. [http://library.linode.com/web-servers/nginx/installation/ubuntu-9.10-karmic#create_an_init_script_to_manage_nginx Create an Init Script to Manage nginx] {en} bietet Hilfe. == nginx startet nicht, da die Konfigurationsdatei angeblich falsch ist == Die Konfigurationsdatei überprüfen, ob überall am Ende jedes Befehls/jeder Zeile ein Semikolon ist, und, ob alle ``server { [...] }``-Blöcke auch mit dem Zeichen "}" geschlossen sind! == Obwohl nginx richtig konfiguriert ist, passiert beim Aufrufen von Subdomains nichts == Bei diesem Problem wird vermutlich eine Fehlkonfiguration der DNS-Zonen vorliegen. == Wieso bleibt nginx an der Meldung "''[...]:80 failed (98: Address already in use)''" hängen? == nginx oder ein anderer Webserver benutzt bereits den Port 80. Es kann immer nur ein Programm an dem Port lauschen. == Wieso kann Plesk nginx nicht konfigurieren? == Das liegt daran, dass [wikipedia:Plesk:] [:Apache:] nutzt und nicht auf nginx zugeschnitten ist. == Wieso wird die neue Konfiguration nicht übernommen? == Für eine Konfigurationsänderung muss nginx neugestartet werden. Wie das geht, steht im Bereich "nginx steuern". == Die Log-Datei bleibt leer, warum? == Falls der Nutzer geändert wurde, mit dem nginx läuft, muss dieser über Schreibzugriff auf diese Datei verfügen. == Weshalb läuft eine FastCGI-Schnittstelle, die andere aber nicht? == Eventuell sollen beide Schnittstellen den selben Port verwenden. Allerdings kann sich jeweils nur eine Schnittstelle an einen Port binden. = Links = * [http://wiki.nginx.org/ nginx Wiki] {en} - Dokumentation * [http://wiki.nginx.org/NginxHttpSslModule SSL mit nginx benutzen] {en} * [http://www.joeandmotorboat.com/2008/02/28/apache-vs-nginx-web-server-performance-deathmatch/ Apache vs Nginx: Web Server Performance Deathmatch] {en} * [http://library.linode.com/web-servers/nginx/ Hosting Websites with Nginx] {en} - Weiterführende Konfiguration #tag: Netzwerk, Internet, Server