NginX – Installation

Das Internet – unendliche Weiten :)
Um unsere Webseiten einem interessierten Publikum zu präsentieren, brauchen wir auf unserem Server einen „Webserver“. Der kümmert sich um das Ausliefern von Internet-Seiten (bildlich gesprochen…). Apache war und ist hier eigentlich der Platzhirsch. Trotzdem möchte ich nun zu NginX wechseln…

NginX wird unter einer BSD-Lizenz veröffentlicht. Und er ist auch schon ‚ganz schön alt‘. Seine Entwicklung begann 2002. Er wird hauptsächlich für den Einsatz in Hochlastumgebungen optimiert. Sein Vorteil liegt darin, eine Vielzahl von parallelen Client-Abfragen bei vergleichsweise geringem Speicherbedarf zu handhaben. Am Anfang war er beim Funktionsumfang dem Apache-Webserver unterlegen. Mittlerweile haben ihn die Programmierer zu einem relativ gleichwertigen, aber ressourcenschonenderem Ersatz gemacht.

Die Entwickler von NginX besitzen darüber hinaus auch eine eigene Firma, über die sie Support und den Webserver „NginX Plus“ unter einer kommerziellen Lizenz mit zusätzlichen Funktionen anbieten.

Seit ein paar Tagen unterstützt dieser NginX Plus das HTTP/2 Protokoll, welches das von Google inspirierte SPDY-Protokoll ablösen wird (http://www.heise.de/newsticker/meldung/Nginx-Webserver-Plus-jetzt-mit-HTTP-2-2821302.html). Bleibt zu hoffen, dass diese Erweiterung auch bald seinen Weg in den ’normalen‘ Community-NginX Server finden wird. Eine ‚Alpha‘ ist jedenfalls etwas zu gewagt für den Einsatz in der ‚freien Wildbahn‘.

Alles in Allem sprechen drei wichtige Gründe für den Einsatz von NginX:

  • Etwa die gleiche Leistung und ein ähnlicher Funktionsumfang von Apache – aber dabei sparsamer! Das ist gerade bei unserem schmalbrüstigen Server ausgesprochen wichtig…
  • Sehr modular zu konfigurieren. Und eigentlich auch recht intuitiv. Die Configs sind ‚lesbar‘ und gut zugänglich.
  • Die SSL-Unterstützung für mehrere unterschiedliche Zertifikate und Domains auf einer IP-Adresse läuft tadellos und ist schnell eingerichtet.

Außerdem bin ich beim Apache über zwei, drei Sachen gestolpert, die bei NginX ‚out of the Box‘ funktioniert haben. Darum ist NginX mein Favorit und wird bei meinen Projekten in Zukunft Apache als Webserver ablösen :)

NginX installieren

Installieren wir NginX einfach per apt-get install nginx, bekommen wir Version v1.2 ausgeliefert. Das wäre an sich kein Problem. Wenn wir aber irgendwann mal SSL mit SPDY verwenden möchten, brauchen wir eine Version >1.4. Darum steigen wir gleich mit v1.6 ein, da ist alles drin und alles dran:
https://wiki.debian.org/Nginx

Dazu müssen wir aber einen „Backport“ für Debian bemühen. Klingt rückwärtsgewandt, bedeutet aber nur, dass eine ‚aktuelle‘ Software in ein ‚altes‘ System eingepflegt wird.

Aber der Reihe nach… Zuvor sollten wir noch ein paar Dinge regeln und klären.

Vorbereitungen

Per SSH als „User“ auf unsere Maschine verbinden

Root-Rechte erlangen
sudo -i

Im Hintergrund größere (4k) Diffie-Hellman Parameter generieren
nohup openssl dhparam -out dhparam4k.pem 4096 && mv dhparam4k.pem /root/CA/certs/ &
(Das „&“ am Schluss ist wichtig und kein Schreibfehler!)
Nach dem Absetzen des Befehls noch einmal „Enter“ drücken. Im Hintergrund werden nun die DH-Parameter berechnet. Die Dauer ist recht zufällig. Habe zwischen 35 und 90 Minuten schon alles erlebt. Da die Berechnung aber abgekoppelt von der Shell im Hintergrund läuft, können wir uns problemlos ausloggen. Der Befehl wird bis zur Fertigstellung abgearbeitet.

Ob der Prozess noch läuft, kannst Du zwischendurch mit einem ps ax abfragen. Du müsstest eine Zeile mit folgendem Inhalt sehen:
3128 pts/0 R 36:13 nohup openssl dhparam -out dhparam4k.pem 4096 && mv dhparam4k.pem /root/CA/certs/
3128 ist die Prozessnummer, die bei Dir sicher anders lautet. Und hier läuft der Befehl schon 36 Minuten, 13 Sekunden.

Wenn die Generierung abgeschlossen ist, bekommst Du folgende Bildschirmausgabe:
[1]+ Fertig nohup openssl dhparam -out dhparam4k.pem 4096 && mv dhparam4k.pem /root/CA/certs/
Die Datei dhparam4k.pem ist dann in den Zertifikate-Ordner der CA verschoben worden. Dort können wir sie später dem Webserver übergeben…

Jetzt noch die nohup.out ansehen und dann löschen
In der nohup.out werden die Ausgaben des Befehls gespeichert, der im Hintergrund läuft. In dem Fall bekommen wir einen Punkte-Salat, der von Pluszeichen durchsetzt ist.
cat /root/nohup.out

rm /root/nohup.out

Seht ihr, das ist so ein Punkt, wo ich nicht weiß, was wir hier genau machen. Diffie-Hellman hat was mit Verschlüsselung zu tun. Es heißt, NginX nutze intern 1024 Bit DH Parameter. Und das wäre mittlerweile unsicher. Wir müssen darum neue Parameter generieren und diese sollen größer sein. SSL-Labs spricht, dass 4096 Bit ausreichen. Und genau das machen wir jetzt…
Aber was GENAU die DH-Parameter machen…? Keine Ahnung :/
In der realen Welt ist das vergleichbar mit mir als Autofahrer, der nicht genau weiß, wie exakt die Diesel-Einspritzpumpe im Motor arbeitet. Aber ich kann das Auto trotzdem von A nach B fahren.

Leider ist so was das Einfallstor von Zeugs in die Anleitung, das mangels genauem Verständnis der Umstände dann einfach übernommen wird. Manche Dinge werde ich einfach glauben, wenn sie in verschiedenen anderen Publikationen übereinstimmend auftauchen. Ob sie deshalb wahr sind? Das steht auf einen anderen Blatt.

Wir öffnen unsere Firewall für die beiden HTTP(s) Ports
nginx-shorewall-rules
nano /etc/shorewall/rules
(ganz unten anfügen)
# WEB – http / https
ACCEPT:info net $FW tcp 80 – –
ACCEPT:info net $FW tcp 443 – –

Firewall neu starten
shorewall safe-restart

Do you want to accept the new firewall configuration? [y/n] y und Enter
New configuration has been accepted

Damit ist die Firewall für Port 80 und 443 offen.

‚Backports‘ zur sources.list hinzufügen
nginx-sources-list-backports
nano /etc/apt/sources.list
(unten die beiden Zeilen anfügen)
# Wheezy Backports
deb http://ftp.de.debian.org/debian/ wheezy-backports main contrib non-free

NginX installieren

apt-get update && apt-get install -t wheezy-backports nginx

[* * * * Bildschirmausgabe * * * *]

Die folgenden zusätzlichen Pakete werden installiert:
init-system-helpers libgd2-noxpm libjpeg8 libpng12-0 libxslt1.1 nginx-common nginx-full
Vorgeschlagene Pakete:
libgd-tools fcgiwrap nginx-doc
Die folgenden NEUEN Pakete werden installiert:
init-system-helpers libgd2-noxpm libjpeg8 libpng12-0 libxslt1.1 nginx nginx-common nginx-full
0 aktualisiert, 8 neu installiert, 0 zu entfernen und 42 nicht aktualisiert.
Es müssen 1.487 kB an Archiven heruntergeladen werden.
Nach dieser Operation werden 3.245 kB Plattenplatz zusätzlich benutzt.

[* * * * Bildschirmausgabe ENDE * * * *]

Standardmäßig wird ein ‚Backport‘ nicht mit Updates versorgt. Das sollten wir ändern…
nano /etc/apt/preferences
# APT PINNING PREFERENCES
Package: *
Pin: release a=wheezy-backports
Pin-Priority: 200

Apache-Utilities installieren
(Brauchen wir für ein Dienstprogramm, das uns später die ‚.htpass‘-Dateien erstellt. Damit sichern wir Webbereiche mit Passwörtern gegen unbefugte Zugriffe ab.)
apt-get install apache2-utils

Globale Einschränkungen erstellen
Ich nenne sie, weil es so schön passt, einfach „nein.conf“. Aber was macht diese Config?

  • ‚favicon.ico‘ nicht gefunden? Nicht loggen… Und auch so nicht ins access-log schreiben.
  • ‚robots.txt‘ nicht gefunden? Nicht loggen… Und auch so nicht ins access-log schreiben.
  • Alle Zugriffe auf Dateien, die mit einem Punkt beginnen, NICHT zulassen. Sichert z.B. unsere .htpass vor neugierigen Blicken!
  • Verweigert das Auflisten von Verzeichnisinhalten, wenn darin eine index.php oder index.html fehlt.

nano /etc/nginx/nein.conf
# Global restrictions configuration file.
# Sollte in jedem ’server {} block‘ laufen.
location = /favicon.ico {
log_not_found off;
access_log off;
}
location = /robots.txt {
allow all;
log_not_found off;
access_log off;
}
# Verhindere alle Zugriffe auf versteckte Dateien (.*) – wie unsere .htpass Datei.
# Diese Zugriffe werden geloggt, damit wir sie später mit einem IDS verarbeiten können (fail2ban)
location ~ /\\. {
deny all;
}
### NO Directory Browsing
autoindex off;
#EOF

SSL-Basiseinstellungen festlegen
(Die ’ssl_ciphers‘ gehören in eine Zeile)
nano /etc/nginx/ssl-base.conf
listen 443 ssl spdy;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers „ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:RSA+AESGCM:RSA+AES:!aNULL:!MD5:!RC4:!3DES:!DSS“;
ssl_dhparam /root/CA/certs/dhparam4k.pem;
ssl_prefer_server_ciphers on;
ssl_session_cache shared:SSL:10m;
ssl_session_timeout 10m;

Basiskonfiguration von NginX anpassen
nginx-conf
nano /etc/nginx/nginx.conf
(‚worker‘ auf 2 stellen, ‚reset_…‘ einfügen. ’server_tokens‘ und die drei ‚gzip-Anweisungen‘ jeweils die Raute löschen und ’scharf schalten‘)

worker_processes 2; ## Für jede CPU einen Worker. Minimal 2, damit nichts klemmt.
reset_timedout_connection on;
server_tokens off;

gzip_vary on;
gzip_buffers 16 8k;
gzip_types text/plain text/css application/json application/x-javascript te …

Im NginX ‚default‘-Eintrag unsere Einschränkungen anwenden
nginx-default-nein
nano /etc/nginx/sites-available/default
(Unter ‚root‘ die ’nein.conf‘ einfügen)
include nein.conf;

NginX neu starten
service nginx restart

Wir müssen IMMER, wenn wir Änderungen an den Config-Dateien vorgenommen haben, NginX neu starten. Sonst werden die Änderungen nicht aktiv…

Und damit haben wir NginX installiert :)
Im nächsten Kapitel fügen wir den PHP-Interpreter hinzu. Damit kann NginX dann dynamische Webseiten ausliefern. Das ist die Grundvoraussetzung für WordPress und viele andere „WEB 2.0“ Technologien.

Haftungsausschluss!

Bitte lies Dir den Disclaimer durch, bevor Du eine Anleitung umsetzt...

Anzeige *

Kommentar verfassen

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.