Seit einigen Tagen habe ich einen neuen Root-Server, der meine Webseite ausliefern soll. Da ich ein bisschen experimentierfreudig bin, habe ich mich zur Installation des Webservers nginx (sprich engine-x) entschlossen, da dieser in vielen Benchmarks noch schneller als lighttpd ist und gleichzeitig weniger RAM verbraucht.
Gleichzeitig sind aber die Rewrite-rules einfacher als beim lighttpd , da diese fast 1:1 vom Apache zu übernehmen sind (was den Umzug der Seiten deutlich einfacher gestaltet). Ich möchte direkt nativ alles über nginx und dessen FastCGI-Backend ausliefern, weshalb ein paar zusätzliche Artikel zu deren Rewrite-Rules oder Stolperfallen bei der Einrichtung kommen werden.
Dieser Artikel ist Teil einer Reihe zum Webserver nginx. Schau dir auch die anderen Artikel an: Zum Leitartikel
Los geht’s mit der Installation von Gentoo, welche ich nach Handbuch durchführe. Hierzu verliere ich keine weiteren Worte, da das Handbuch wirklich umfangreich und ausreichend ist. Wichtig ist, dass Portage auf dem aktuellen Stand ist, das sollte aber nach der Installation der Fall sein.
Ich wollte den nginx mit den zusätzlichen Modulen FastCGI , PCRE, SSL , Stub_Status , WebDAV und zlib , weshalb ich die folgenden USE-Flags hinzugefügt und anschließend den nginx installiert habe:
|
|
Zum Zeitpunkt des Schreibens wird Version 0.7.61 installiert.
Nach dem emergen von Nginx kommt bei mir die Konfiguration von PHP. Ich fahre schon seit Ewigkeiten mod_fcgid unter Apache, welcher die Verwaltung (Starten/Stoppen/Steuerung) der PHP-Prozesse selbst übernimmt. Bei nginx wird das etwas anders angesteuert, da die PHP-Prozesse schon existieren müssen und nginx diese nicht selbst erstellt. Um dies zu vereinfachen, gibt es das Project spawn-fcgi , welches aus dem Webserverprojekt lighttpd ausgegliedert wurde.
Zum Zeitpunkt dieses Tutorials ist dieses Paket in Gentoo noch nicht als stable gekennzeichnet, weshalb man es vor der Installation möglicherweise erst freischalten muss:
|
|
Jetzt sollte man sich ein paar Gedanken zur Aufteilung der Webserverhosts über die PHP-Prozesse machen. Dazu muss man ein wenig Hintergrund zur FastCGI -Technologie kennen. Zur Verarbeitung der PHP-Seiten wird ein PHP-Interpreter gestartet mit dem der Webserver über einen Unix-Socket oder einen TCP-Port kommuniziert. Diese Interpreter kann man unter einem anderen Nutzer (als root) starten, wodurch ein wenig zusätzliche Sicherheit geschafft wird, wenn dieser Nutzer weniger Rechte hat. Im Idealfall sollte man also für jeden Vhost einen eigenen PHP-Interpreter und Nutzer haben, um die höchste Sicherheit zu erhalten. Leider benötigt jeder Interpreter ein wenig RAM, sodass man sich überlegen sollte, wieviele man davon gleichzeitig im RAM halten möchte. Ich habe für mich einen Mix aus Performance und Sicherheit gewählt. Ich zeige mal an einem Vhost, wie man diese PHP-Interpreter startet.
Startet man nun /etc/init.d/spawn-fcgi
, so wird man ermahnt, dass das so nicht funktioniert:
- You are not supposed to run this script directly. Create a symlink
- for the FastCGI application you want to run as well as a copy
- of the configuration file and modify it appropriately like so…
- ln -s spawn-fcgi /etc/init.d/spawn-fcgi.trac
- cp /etc/conf.d/spawn-fcgi /etc/conf.d/spawn-fcgi.trac
- nano /etc/conf.d/spawn-fcgi.trac
Folglich führe ich diese Schritte für meinen ersten FastCGI-Server durch:
|
|
Jetzt muss man die Konfigurationsdatei /etc/conf.d/spawn-fcgi.wolfuli
editieren:
FCGI_SOCKET= FCGI_ADDRESS=127.0.0.1 FCGI_PORT=1234 FCGI_PROGRAM=/usr/bin/php-cgi FCGI_CHILDREN=1 FCGI_CHROOT= FCGI_CHDIR= FCGI_USER=wolfuli FCGI_GROUP=wolfuli PHPRC="/var/www/php-ini/wolfuli/" PHP_FCGI_CHILDREN=10 PHP_FCGI_MAX_REQUESTS=1000 ALLOWED_ENV="PATH PHP_FCGI_CHILDREN PHP_FCGI_MAX_REQUESTS PHPRC"
Über die Variable PHPRC wurde ein Verzeichnis festgelegt, in dem man man eine, für den Vhost angepasste, php.ini hinterlegen kann.
Jetzt muss man noch den Nutzer wolfuli samt der gleichen Nutzergruppe anlegen:
|
|
Jetzt richten wir mal unsere Vhosts ein. Aus praktischen Gründen habe ich mich entschlossen ein “sites-available” und ein “sites-enabled”-Verzeichnis anzulegen.
|
|
So kann ich Vhosts im ordner sites-available konfigurieren und dann diese dann in sites-enabled softlinken, wenn sie aktiv sein sollen. So kann ich mal vhosts abschalten ohne diese gleich löschen zu müssen.
Die /etc/nginx/nginx.conf
habe ich ebenfalls ein wenig abgeändert, sodass diese wie folgt aussieht:
|
|
Wie man sieht, ist nun in der letzten Zeile ein include aller Vhosts aus dem “sites-enabled
"-Verzeichnis. Die Variable “worker_processes
” sollte auf die Anzahl der CPU-Kerne gesetzt werden, was in meinem Falle zwei sind.
Damit ist die Installation abgeschlossen, jetzt kann man nun einen PHP-VHost anlegen. Dazu muss zunächst die Datei /etc/nginx/fastcgi_params angelegt bzw. modifiziert werden, sodass diese so aussieht:
|
|
Diese Datei legt einige Parameter im Zusammenspiel von PHP (FastCGI) und nginx fest.
Hier der Beispielvhost example.com, welcher unter /etc/nginx/sites-available/example.com
angelegt wird:
|
|
Jetzt muss man den fertigen Vhost nur noch softlinken:
cd /etc/nginx/sites-enabled/ ln -s ../sites-available/example.com
Und nginx die neuen Konfigurationsdateien lesen lassen:
/etc/init.d/nginx reload
Das wars. Lies auch die anderen Artikel zu diesem Thema in diesem Leitartikel.