[HOWTO] LEMP Stack + SSL - Debian 6.0

4.)nginx
Kommen wir nun zum Sahnehäubchen: Dem Webserver nginx, also dem Herzstück unserer LEMP Umgebung.
Installation:

:~$ sudo apt-get install nginx

Starten/Stoppen lässt sich nginx wie auch die anderen Serverdienste per init-Skript, es liegt unter /etc/init.d/nginx

Die Konfigurationsdatei von nginx liegt unter /etc/nginx/nginx.conf
Folgende, wichtigste Einstellungen solltet ihr an euer System anpassen:

user www_data; #Unter welchem Nutzer soll nginx laufen? Default & empfohlen: www-data
worker_processes 5; #Wieviele Prozesse darf nginx spawnen? Empfohlen: 12-24, maximal jedoch soviele wie Prozessoren im System verbaut sind.




worker_connections 1024; #Legt fest, wieviele Verbindungen pro Prozess erlaubt sind. Maximale Verbindungen von nginx: worker_processes * worker_connections




access_log /var/log/nginx/access.log; #Speicherort des Globalen Zugriffslogs, sollte in /var/log/nginx liegen

Das war die Serverkonfiguration. Jetzt müssen die sog. Virtual-Hosts konfiguriert werden.
Ein vHost(Virtual-Host) repräsentiert quasi einen virtuellen Webserver, sodass ein nginx Server mehrere Seiten hosten kann.
Weitere infos: Virtual Hosting – Wikipedia
Dafür gibt es zwei ordner:

• /etc/nginx/sites-available
• /etc/nginx/sites-enabled

Sämtliche vHosts werden in "sites-available" erstellt und dann eine Verknüpfung auf sie in "sites-enabled" angelegt.
Zuersteinmal wollen wir den "Default" loswerden, lösche also dazu die Verknüpfung:

:~$ rm /etc/nginx/sites-enabled/default

Erstellt jetzt eine Datei, die wie eure Domain heißt im Ordner "sites-available" mit folgendem, angepasstem Inhalt:

#vHost Configuration File:
#vHost: beispiel.de
server {
         	listen 80; ##Der Port, HTTP benötigt Port 80
         	server_name beispiel.de www.beispiel.de; ##Auf welche Domains soll der vhost "reagieren"




         	access_log /var/log/nginx/vleupi.de.access_log; ##Logfile für die Zugriffe
         	error_log /var/log/nginx/vleupi.de.error_log; ##Logfile für die Fehler




         	root /var/www/beispiel.de; ##Verzeichnis, in welchem die Website gehostet wird
         	index index.php index.htm index.html; ##Welche dateien zählen als index ?




         	###PHP Configuration
         	location ~ .php$ {
         	         	fastcgi_pass 127.0.0.1:9000;
         	         	fastcgi_index index.php;
         	         	fastcgi_param SCRIPT_FILENAME /var/www/beispiel.de$fastcgi_script_name;
         	include fastcgi_params;
         	}




         	##Sperre zugriff auf versteckte Daten
         	location ~ /\. {
         	         	deny all;
         	}
}

die Erklärungen zu den Werten sind als Kommentare in der Datei verfasst.
Diese Beispielkonfiguration "/etc/nginx/sites-available/beispiel.de" hostet z.B. die Seite "Beispiel.de" im Verzeichnis "/var/www/beispiel.de".

Um die Konfiguration anzuschalten, muss nun noch eine Verknüpfung im "sites-enabled" Ordner angelegt werden:

:~$ ln -s /etc/nginx/sites-available/beispiel.de /etc/nginx/sites-enabled/beispiel.de

Dann muss nginx via init-Skript neugestartet werden.
Das schöne an nginx: Passt seine Konfiguration nich genau/ist stark unsicher, so verweigert er den Start. Startet nginx, habt ihr also alles richtig gemacht.

Wer eine Zugriffsverwaltung ala .htaccess umsetzen möchte, dem sei folgende Seite aus der nginx-Dokumentation ans Herz gelegt, welche das sehr schön erläutert:
HttpAuthBasicModule

5.) SSL
5.1) Voraussetzungen
Es muss bereits ein gültiges SSL-Zertifikat vorhanden sein! Wie man kostenlos an ein SSL-Zertifikat kommt, das immerhin ein Jahr lang gültig ist, erklärt Heise Security sehr schön:
SSL für lau | heise Security
(Natürlich nur bis zu dem Punkt, wo man alle Zertifikate runterlädt; Das Einspielen in den Apache ist für uns natürlich nicht wichtig)
Und wem das ein wenig zu schnell ging, findet hier noch eine etwas ausführlichere Anleitung:
SSL für lau Kostenlose Zertifikate einrichtenLazybone | Lazybone

Ich gehe von folgendem Start-Szenario aus:
Im HOME Ordner eures Benutzers liegen folgende Zertifikatsdateien(hier wieder am beispiel.de):

• beispiel.de.crt <- Public Key, Bekommt ihr von StartSSL / Eurer CA
• beispiel.de.key <-Private Key, Bekommt ihr von StartSSL / Eurer CA
• sub.class1.server.ca.pem (oder ähnlich) <-
• CertificateChain: Wird benötigt, um euer Zertifikat euer CA zuzuweisen,
• bekommt ihr auch von eurer CA

Die CertificateChain für StartSSL bekommt ihr übrigens unter
Index of /certs , die Datei heißt "sub.class1.server.ca.pem"

Jetzt müssen wir noch einen letzten Schritt durchführen, bevor wir die Zertifikate an die passenden Stellen kopieren können:
Wirmüssen an unser Server-Zertifikat (beispiel.de.crt) noch die sog. Authentifizierungskette(CertificateChain) anhängen, dass auch nachvollzogen werden kann, dass unser Zertifikat von ihr kommt. Das erledigt folgender Befehl und speichert das entstehende Zertifikat als "beispiel.de.chained.crt"

:~$ cat beispiel.de.crt sub.class1.server.ca.pem > beispiel.de.chained.crt

Passt in diesem Befehl die Dateinamen euren einfach an.
Wichtig:
Die Reihenfolge darf nicht vertauscht werden, sonst wirft nginx beim
starten einen Fehler. Sie muss immer folgendem Muster folgen:

:~$ cat PublicKeyFile.crt CertificateChainFile.XXX > ChainedPublicKeyFile.crt

Die CertificateChainFile kann verschiedene Endungen besitzen, am Gebräuchlichsten sind ".crt" und ".pem"

Habt ihr diese Datei hergestellt, erstellt folgende Ordner:

• /etc/ssl
• /etc/ssl/certs #Für öffentliche Schlüssel, CertificateChains
• /etc/ssl/private #Für unsere Privaten Schlüssel

Kopiert in "/etc/ssl/certs" folgende Dateien: "beispiel.de.crt", "beispiel.de.chained.crt". "sub.class1.server.ca.pem"
Kopiert in "/etc/ssl/certs" folgende Datei: "beispiel.de.key"

Das wars, jetzt müssen wir nginx nur noch beibringen, diese Zertifikate auch zu verwenden.

5.2) nginx und SSL
Der Beispiel vHost, welcher uns schon bekannt ist, jetzt aber sowohl http-, als auch https-Verbindungen unterstützt:

#vHost Configuration File:
#vHost: beispiel.de, SSL Enabled
server {
         	listen 80;
         	listen 443 default ssl; ##HTTPS Access
         	server_name beispiel.de www.beispiel.de;




         	ssl_certificate /etc/ssl/certs/beispiel.de.chained.crt; #Public Key incl. CertificateChain
         	ssl_certificate_key /etc/ssl/private/beispiel.de.key; #Private Key




         	access_log /var/log/nginx/beispiel.de.access_log;
         	error_log /var/log/nginx/beispiel.de.error_log;




         	root /var/www/beispiel.de;
         	index index.php index.htm index.html;




         	location ~ .php$ {
         	         	fastcgi_pass 127.0.0.1:9000;
         	         	fastcgi_index index.php;
         	         	fastcgi_param SCRIPT_FILENAME /var/www/beispiel.de$fastcgi_script_name;
         	         	include fastcgi_params;
         	}




         	location ~ /\. {
         	         	deny all;
         	}
}

Die Parameter die neu dazukamen, wurden entsprechend Kommentiert.

Um die Änderungen zu Übernehmen, muss nginx neugestartet werden.

5.3) Troubleshooting

Wenn nginx mit folgender Fehlermeldung versagt, wurden die Parameter beim generieren der CertificateChainKeyFile vertauscht, die Datei beispiel.de.chained.crt ist also falsch:

SSL_CTX_use_PrivateKey_file(" ... /www.example.com.key") failed
         	(SSL: error:0B080074:x509 certificate routines:
         	X509_check_private_key:key values mismatch)

Bei diesem Schritt muss die Reihenfolge genau eingehalten werden.

6) Testen:

Jetzt können wir die Umgebung testen. Dazu müssen alle installierten und konfigurierten Server gestartet werden.

Dann erstellen wir im Verzeichnis der Website (hier: /var/www/beispiel.de/) die Datei index.php

Und füllen sie mit folgendem Inhalt:

<?php
          	phpinfo();
?>

Jetzt müssen wir sie nur noch dem passenden Nutzer zuordnen, sodass nginx auch darauf zugreifen kann:

:~$ chown -R www-data:www-data /var/www/beispiel.de

Dieser Befehl setzt im ganzen Ordner /var/www/beispiel.de die Zugriffsrechte
passend, sodass nginx, der unter www-data läuft darauf zugrifen kann.

Startet jetzt nginx neu.

Jetzt kann man im Browser auf seine Domain gehen(hier Beispiel.de) und bekommt eine PHP-Info Seite angezeigt. Wenn man "https://beispiel.de" besucht, so sollte die Verbindung mit https gesichert sein. Bekommt man eine Warnung, dass das Zertifikat nicht verifiziert werden kann und aus einer unbekannten Quelle stamme, so hat dies eine(oder beide) der beiden Ursachen:

• Beim Einbinden der CertificateChain ist etwas schiefgelaufen, daher kann deine CA nicht ausfindig gemacht werden
• Deine CA ist nicht vertrauenswürdig(z.B. eigens erstellte CA)

Um das erstere zu Beheben musst du die Schritte oben zum Einbinden wiederholen oder diverse Suchmaschinen/Foren bemühen. Das zweite ist ein anderes Problem: In gängigen Browsern werden nur Zertifikate von großen CA´s akzeptiert. Eigene CA´s / kleine CA´s produzieren eine Sicherheitswarnung. Jedoch kannst du in deinem Betriebssystem das
Zertifikat der CA installieren, dann wird von diesem Rechner der CA ebenfalls vertraut. Auch hierfür konsultierst du am besten eine Suchmaschine/ ein Forum.

Nach einem erfolgreichen Test sollte die Datei in

<?php
          	echo "Hello World!";
?>

umgeändert werden, da der phpinfo(); Befehl sehr viel über das installierte PHP System preisgibt.

Wenn ihr die Datei jetzt mit root Rechten geändert habt, müsst ihr nocheinmal obigen "chown befehl" ausführen!

Das wars, ihr habt jetzt ein fertiges und schnelles System, das noch dazu wenig Ressourcen braucht. Glückwunsch!

Ich hoffe, dieses Howto hat ein wenig Licht in die Lage nginx/SSL gebracht und dem ein oder anderen geholfen.

PS: Bestünde Interesse an einem Howto über PHP Beschleuniger?

Danke für den Tipp

Sonst noch irgendwas verbesserungswürdiges entdeckt?

Dankeschön

Leider kann ich den Vorschlag mit dem Socket nicht einarbeiten, da ich den Beitrag ned mehr editieren kann

Leider komme ich im Moment wenig zum schreiben, sonst würde ich ne bessere Version nachschieben, aber das sollte in ca. 2 Wochen vorbei sein.

Zu einigen Sachen oben möchte ich trotzdem was schreiben, auch wenn es sicher schon ein paar Tage her sein mag

@Slavit: Bei den KVM Servern: Ja, im Prinzip schon, aber bei wenigen Kernen kann man auch von dieser groben Maßgabe abweichen
Es ist nur folgendes wichtig: Man sollte sich im klaren sein, dass ein Linux-Server jedem Prozess/Thread möglichst gleich viel Rechenzeit geben möchte(sog. Scheduling). Hat man pro Kern also 10 Threads, bekommen alle 10 nur jeweils 1/10 der Rechenzeit. D.h. man hat de facto keinen Performancegewinn gegenüber 5 Threads(zumindest nicht spürbar), welche jeweils 1/5 der Rechenzeit bekommen. Der Vorteil an der einstellbaren Threadanzahl sind die "ganz normalen" vServer von netcup: Da man bis zu 24 Prozessorkerne nutzen kann, kann man auch 24 Kernen Aufgaben zuweisen für maximale Parallelität und kein Kern ist untätig.

Bei deinem KVM Server würde ich eine Threadanzahl zwischen 2 und 6 empfehlen. Weniger macht keinen Sinn, da sonst ein Kern nicht ausgelastet wäre, mehr auch nicht, da sich die nginx Threads sonst dank Linux-Scheduling selbst im Weg sind(zumindest, wenn du nicht grade planst, einen riesigen Internetauftritt zu hosten).

Dirk67:

Zu den Werten für die Performance:

pm.max_children = 9
pm.start_servers = 3
pm.min_spare_servers = 2
pm.max_spare_servers = 4
pm.max_requests = 200

Die Schalter müssten, wie bereits erwähnt, schon in den Pool-Dateien stecken, wenn nicht schreib sie da einfach rein
Wobei ich über gute und schnelle Konfiguration sowieso noch ein Howto machen würde.
Dieses war dediziert eigentlich nur zur Einrichtung da

Das mit dem Socket war ja dann auch schon geklärt

Wisst ihr wie/ob man hier als Kunde denn was ins Netcup Wiki schreiben kann?

\TIA