... | ... | @@ -3,7 +3,7 @@ |
|
|
|
|
|
## Allgemeines
|
|
|
|
|
|
Nginx ermöglicht es nicht eine Config-datei im DokumentRoot des VHosts anzulegen, wie Apache es mit der .htaccess handhabt.
|
|
|
Nginx ermöglicht es nicht eine Config-datei im DokumentRoot des VHosts anzulegen, wie Apache es mit der `.htaccess` Datei handhabt.
|
|
|
Anstatt dessen liest Nginx Directory bezogene Anweisungen beim Dienststart ein.
|
|
|
Diese Anweisungen werden in einer zentralen Config-Datei verwaltet und bestehen aus Anweisungsblöcken.
|
|
|
Die zwei Hauptarten jener Blöcke sind Server- und Location-Blöcke.
|
... | ... | @@ -32,7 +32,7 @@ Dort findet man die nginx.config sowie einen Unterordner "sites-available" |
|
|
/etc/nginx/sites-available/
|
|
|
|
|
|
Dieser Unterordner dient für vHost-bezogene config Dateien, welche in die Haupt-Config eingebunden werden.
|
|
|
Um die Nginx config für Quiqqqer wirksam zu machen legen wir eine neue Datei in diesem Unterordner an.
|
|
|
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
|
... | ... | @@ -63,7 +63,7 @@ Darauf folgt eine Verifikation der Configdatei und ein restart von nginx. |
|
|
|
|
|
### Installation GeoIP Module
|
|
|
|
|
|
Um das GeoIP Module im Nginx zu aktivieren muss der http-Block (z.b. `nano /etc/nginx/nginx.conf`) um folgende einträge ergänzt werden.
|
|
|
Um das GeoIP Module im Nginx zu aktivieren, muss der http-Block (z.b. `nano /etc/nginx/nginx.conf`) um folgende einträge ergänzt werden.
|
|
|
|
|
|
```
|
|
|
http {
|
... | ... | @@ -154,24 +154,26 @@ Wobei der Modifier wie folgt ausfallen kann : |
|
|
| \^\~ | 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.
|
|
|
|
|
|
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 Location-Block aufgebaut ist, werden wir nun genauer betrachten, wie der Server den zu verwendenden Locationblock auswählt.
|
|
|
|
|
|
Da wir nun betrachtet haben, wie ein Location-Block aufgebaut ist, werden wir nun genauer betrachten, wie der Server den zu verwendenden Location-Block auswählt.
|
|
|
|
|
|
Nginx verwendet einen umfangreichen Algorithmus, welcher bei jedem Request einen passenden Location-Block sucht.
|
|
|
|
|
|
Kurz zusammengefasst sehen die Schritte wie folgt aus:
|
|
|
|
|
|
- Prüfe nicht Reguläre Ausdrücke
|
|
|
- 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
|
|
|
- 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)
|
|
|
|
... | ... | @@ -186,7 +188,7 @@ Kurz zusammengefasst sehen die Schritte wie folgt aus: |
|
|
|
|
|
**Zu beachten:**
|
|
|
|
|
|
Bei machen Anweisungen, wird der Algorithmus von vorne gestartet, wenn ein interner Redirect stattfindet und nicht explizit verhindert wird.
|
|
|
Bei manchen 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!
|
|
|
|
|
|
|
... | ... | @@ -201,14 +203,14 @@ Im Location-Block hat man nun diverse Konfigurationsmöglichkeiten. Unter ander |
|
|
|
|
|
**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.
|
|
|
- `return`: Stoppt die weitere Bearbeitung des Requests und sendet eine Statuscode zurück. Entweder ein redirect oder ein Statuscode mit Response-Text.
|
|
|
|
|
|
- `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
|
|
|
- `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**
|
|
|
**Mehr zu der Direktive: `rewrite`**
|
|
|
|
|
|
**Allgemeines Format : ** rewrite \<RegEx-pattern\> \<replacement\> [flag]
|
|
|
|
... | ... | @@ -220,7 +222,7 @@ Soweit nicht durch Flags behandelt, wird auf die neu entstandene URI erneut eine |
|
|
|
|
|
- `last`: Hört sofort mit Bearbeitung des Requests auf und sucht sofort nach neuen Location Blöcken
|
|
|
|
|
|
- `break`: Stoppt Bearbeitung des Requests und sucht **keine** neue Locationblöcke.
|
|
|
- `break`: Stoppt Bearbeitung des Requests und sucht **keine** neuen Location-Blöcke.
|
|
|
|
|
|
|
|
|
## Vertiefende Literatur
|
... | ... | |