Skip to content

QUIQQER / QUIQQER

Go to a project
Nginx konfiguration

Nginx konfiguration

Last edited by Florian
Page history

Nginx Config

Allgemeines

Nginx ermöglicht es nicht eine Config-datei im Verzeichnis anzulegen, wie Apache es mit der .htaccess handhabt.
Anstatt dessen liest Nginx Directorybezogene Anweisungen beim Dienststart ein.
Diese Anweisungen werden in einer Zentralen ConfigDatei verwaltet und bestehen aus Anweisungsblöcken.
Die zwei Hauptarten jener Blöcke sind Server- und Locationblöcke.

Nginx config für Quiqqer

Bitte beachten Sie, dass folgende Angaben nicht blind kopiert werden sollten. Eventuell verwendet ihr System andere Pfade oder Pakete wie "nano" sind nicht installiert. Folgende Angaben sind also ohne Gewähr und dienen eher als Leitfaden und Beispiel.

Quiqqer bietet die Möglichkeit die Nginx config generieren zu lassen. Dafür muss die quiqqer.php in der Console aufgerufen werden. 

php quiqqer.php

Dort meldet man sich mit den Admin-Zugangsdaten an und ruft das tool Nginx auf :

quiqqer:nginx

Dieses Tool erstellt die Nginx-Config im Rootverzeichnis von Quiqqer.
Den Inhalt dieser Configdatei kopiert man nun und fügt sie in die NginX config ein.
Diese residiert im Normalfall unter :

/etc/nginx/

Dort findet man die nginx.config sowie einen Unterordner "sites-available"

/etc/nginx/sites-available/

Dieser Unterordner dient für Vhostbezogene config Dateien, welche in die Hauptconfig eingebunden werden.
Um die Nginx config für Quiqqqer wirksam zu machen legen wir eine neue Datei in diesem Unterordner an.

cd /etc/nginx/sites-avilable    
sudo nano quiqqer.conf

Nun öffnet sich nano und man kopiert den Inhalt der generierten ConfigDatei in den soeben geöffneten Texteditor. Abschliessend speichert man die Änderungen.

Crtl +x
Mit  "yes"  bestätigen

Um die Configdatei nun zu "aktivieren" müssen wir einen symbolischen Link von "sites-enabled" nach "sites-available" erstellen.

cd /etc/nginx/sites-enabled
ln -s /etc/nginx/sites-enabled/quiqqer.conf /etc/nginx/sites-available/quiqqer.conf

Darauf folgt eine Verifikation der Configdatei und ein restart von nginx.

nginx -t     # Prüft die Config Dateien
service nginx restart

Aufbau der Nginx config

Http Block

Der Http Block enthält alle Server übergreifenden Konfigurationen.

Server Block

Der Serverblock enthält Anweisungen, die den VHost betreffen.
Also insbesondere die IP bzw. den Port auf welchen der VHost reagiert und auf welche Domain er ansprechen soll.

listen: Angabe auf welcher IP-Adresse/welchem Port reagiert werden soll .
Beispiel : listen 0.0.0.0:80; oder listen 80;

server_name: Angabe auf welche Domain reagiert werden soll. Je genauer, desto höher die Priorität.
Beispiel : *.example.com oder example.com

Location Block

Ein Serverblock kann mehrere Locationblöcke beinhalten.
Locationblöcke sind grundlegend das Äquivalent zur .htaccess Datei.
Sie ermöglichen Konfigurationsdirektiven zu einem bestimmten Ort anzugeben.

Die Syntax des Location-Blocks ist wie folgt :
location modifier path { Anweisungen }

Wobei der Modifier wie folgt ausfallen kann :

Modifier Bedeutung
(leer) Prüft als Prefix. matcht, wenn URI damit anfängt
= Exakt. Matcht nur bei exaktem Treffer.
~ RegEx. Matcht einen Regulären Ausdruck.
~* RegEx. Matcht einen case-insensitiven Regulären Ausdruck
^~ Versucht diesen String in der Url zu finden. Verhindert RegEx matching

Path
Der path Beschreibt die request_uri, als den Teil nach der Host-Angabe.
Hierbei ist zu beachten, dass Nginx einen führenden "/" beachtet.
http://localhost/test/ müsste also mit location = /test/ gematcht werden.

Reihenfolge der Selektion
Da wir nun betrachtet haben, wie ein Locationblock aufgebaut ist, werden wir nun genauer betrachten, wie der Server den zu verwendenden Locationblock auswählt.

Nginx verwendet einen umfangreichen Algorithmus, welcher bei jedem Request einen passenden Locationblock sucht.

Kurz zusammengefasst sehen die Schritte wie folgt aus :

  • Prüfe nicht Reguläre Ausdrücke

    • Suche zuerst exakte treffer (= modifier)
    • Als nächstes werden Prefix-matches gesucht, je länger, desto höher die Priorität
    • Falls beim längsten Prefix-treffer ein ^~ modifier verwendet wird, wird dieser Treffer sofort verwendet (verhindert RegEx-Prüfung)
    • Falls kein modifier verwendet wird, speichere besten Treffer zwischen

  • Prüfe nun, ob RegEx Treffer möglich sind (Reihenfolge wie in der ConfigDatei)

    • Hier gilt, der erste Treffer gewinnt.

  • Falls kein Match durch RegEx erzielt werden konnte, verwende zwischengespeicherten Prefix-Match.

Zu beachten:

Bei machen Anweisungen, wird der Algorithmus von vorne gestartet, wenn ein interner Redirect stattfindet und nicht explizit verhindert wird. Das heißt, es ist möglich in Endlosschleifen zu geraten!

Die Anweisungen

Da wir nun wissen, welcher Block selektiert wird, sollten wir uns damit befassen, was der Block bewirken kann.

Im Locationblock hat man nun diverse Konfigurationsmöglichkeiten. Unter anderem :

index: Man kann die Indexdatei festlegen
root: Man kann den DirectoryRoot erneut festlegen

Besonderes Augenmerk legen wir aber auf die folgenden Direktiven:

  • return : Stoppt die weitere Bearbeitung des Requests und sendet eine Statuscode zurück. Entweder ein redirect oder ein Statuscode mit Responsetext.

  • rewrite: Schreibt einen Teil der URI um und führt einen internen redirect aus.

  • try_files : Prüft gegebene Dateien / Ordner auf Existenz, falls keine davon existiert wird ein interner redirect auf den letzten Parameter ausgeführt

Mehr zu der Direktive : rewrite

*Allgemeines Format : * rewrite <RegEx-pattern> <replacement> [flag]

Ersetzt den Teil der URI, der das RegEx-Pattern "matcht" durch das angegeben Replacement.
Soweit nicht durch Flags behandelt, wird auf die neu entstandene URI erneut eine Suche nach passenden Locationblöcken gestartet.

Flags :

  • last : Hört sofort mit Bearbeitung des Requests auf und sucht sofort nach neune Location Blöcken

  • break : Stoppt Bearbeitung des Requests und sucht keine neue Locationblöcke.

Vertiefende Literatur