Bei den meisten Installationen unter Apache läuft PHP als Modul. Das heisst, für das Ausführen von PHP muß kein neuer Prozess gestartet werden, sondern die Verarbeitung bzw. Parsen der PHP-Dateien übernimmt das beim Start des Apachen geladene PHP-Modul. Für nginx gibt es solch ein Modul nicht, weshalb wir auf die CGI-Version von PHP zurückgreifen müssen. Dies ist nicht weiter tragisch, da die Performance – eine halbwegs schnelle CPU vorausgesetzt – aus Erfahrung nicht darunter leidet. Doch wie konfiguriert man nginx, um ihn für das Ausliefern von dynamischen PHP-Scripts vorzubereiten?

Installation von PHP5-CGI

Zuallererst benötigen wir nun die CGI-Version von PHP. Falls sie noch nicht installiert ist, können wir sie entweder selbst kompilieren oder verwenden von der Linux-Distribution bestehende Pakete. Für Ubuntu ist die Installation hier mit einer Zeile erledigt:

# apt-get install php5-cgi

Sofern man für WordPress zum Beispiel noch mehr Module wie MySQL oder GD benötigt, könnte die Zeile auch so aussehen:

# apt-get install php5-cgi php5-dev php5-gd php5-mysql

Die Verbindung zu nginx: Sockets für PHP

Damit wir PHP mit nginx nutzen können, benötigen wir sogenannte Sockets unter denen das PHP auf Anfragen von nginx wartet, wahlweisse als TCP- oder UNIX-Domain-Socket. Da ein Socket ständig auf neue Verbindungen wartet, muß ein neuer Prozess erzeugt werden, der diese Arbeit übernimmt. Dieser Prozess erzeugt weitere Unterprozesse und leitet die PHP-Anfragen dann an diese weiter.

Es gibt nun mehrere Möglichkeiten die PHP-Prozesse zu starten. Die Aufgabe ist hier, die Prozesse als Daemon und unter einem anderen User laufen zu lassen, sowie die Standard- und Fehler-Ausgaben umzuleiten.
Zwei Möglichkeiten möchte ich hier aufzeigen: Zum einen kann man die Prozesse ganz normal per Startscript starten, auf Ubuntu zum Beispiel mit dem start-stop-daemon. Zum anderen gibt es Tools wie spawn-fcgi, mit dem ich jedoch nicht so gute Erfahrungen gemacht habe, da es bei mir öfters, teilweisse sogar mit Segfaults, unter Last abstürzte. Da ich aber keine Zeit hatte, dem Grund auf die Spur zu gehen und PHP mit dem start-stop-daemon bei mir ziemlich gut läuft, möchte ich euch spawn-fcgi der Vollständigkeithalber nicht vorenthalten. Sicher auch hilfreich für andere Linux-Distributionen.

PHP im FASTCGI-Modus mit Startscript

Die in PHP mitgelieferte CGI-Version php5-cgi erledigt im FastCGI-Modus die Socketbindung und das Erzeugen von neuen Prozessen selbstständig und sehr zuverlässig. Zum Starten benötigen wir ein Startscript, welches wir unter /etc/init.d/fastcgi anlegen:

# vi /etc/init.d/fastcgi

Inhalt:

#!/bin/bash
BIND=127.0.0.1:8088
USER=www
PHP_FCGI_CHILDREN=15
PHP_FCGI_MAX_REQUESTS=1000
PHP_CGI=/usr/bin/php5-cgi

PHP_CGI_NAME=`basename $PHP_CGI`
PHP_CGI_ARGS="- USER=$USER PATH=/usr/bin PHP_FCGI_CHILDREN=$PHP_FCGI_CHILDREN PHP_FCGI_MAX_REQUESTS=$PHP_FCGI_MAX_REQUESTS $PHP_CGI -b $BIND"
RETVAL=0

start() {
    echo -n "Starting PHP FastCGI: "
    start-stop-daemon --quiet --start --background --chuid "$USER" --exec /usr/bin/env -- $PHP_CGI_ARGS
    RETVAL=$?
    echo "$PHP_CGI_NAME."
}
stop() {
    echo -n "Stopping PHP FastCGI: "
    killall -q -w -u $USER $PHP_CGI
    RETVAL=$?
    echo "$PHP_CGI_NAME."
}

case "$1" in
   start)
    start
;;
   stop)
    stop
;;
   restart)
    stop
    start
;;
   *)
    echo "Usage: php-fastcgi {start|stop|restart}"
    exit 1
;;
esac
exit $RETVAL


Die ersten fünf Variablen werden zur Konfiguration benötigt und bedeuten folgendes:

BIND: IP-Adresse und Port, unter denen auf Verbindungen gewartet wird
USER: Benutzer, unter dem die Prozesse laufen
PHP_FCGI_CHILDREN: Anzahl der zu forkenden bzw. erstellenden Prozesse
PHP_FCGI_MAX_REQUESTS: Anzahl von Requests, nach denen der Prozess stirbt (neue werden automatisch erstellt)
PHP_CGI: Pfad zu php5-cgi

Evtl. muß nun noch der Pfad zu php5-cgi und der Benutzer angepasst werden und wir können das Script nach einem chmod ausführen:

# chmod 700 /etc/init.d/fastcgi
# /etc/init.d/fastcgi start


Mit dem Befehl “ps ax” sollten wir nun in der Prozessliste unsere PHP-Prozesse laufen sehen und gehen jetzt zur nginx-Konfiguration über.

Fast-CGI mit spawn-fcgi

spawn-fcgi macht eigentlich auch nichts anderes als das Startscript unter Ubuntu. Es erstellt einen TCP/Unix-Domain-Socket und die gewünschte Anzahl von Prozessen unter einem bestimmten Benutzer und leitet die Ausgaben ensprechend um. Zur Installation benötigen wir natürlich die aktuellen Sourcen von spawn-fcgi, deren Link wir auf der News-Seite des Projektes erhalten. Download, Entpacken und ins Verzeichnis wechseln:

# wget http://www.lighttpd.net/download/spawn-fcgi-1.6.3.tar.gz
# tar -xvzf spawn-fcgi-1.6.3.tar.gz
# cd spawn-fcgi-1.6.3


Nun folgt das bekannte Zweiergespann zum Kompilieren. spawn-fcgi besitzt keine Install-Routine, weshalb wir dies selbst vornehmen müssen:

# ./configure
# make
# cp ./src/spawn-fcgi /usr/bin/spawn-fcgi


Nun können wir das Tool das erste mal starten.

/usr/bin/spawn-fcgi -a 127.0.0.1 -p 8088 -F 3 -u www -f /usr/bin/php5-cgi

Die Bedeutung der Optionen:

-a    IP-Adresse, an der auf Verbindungen gewartet wird
-p    Port, an dem auf Verbindungen gewartet wird
-w    User unter dem die Prozesse laufen sollen
-f    Pfad zum PHP-CGI
-F    Anzahl der Prozesse, die geforkt werden sollen

Konfiguration des nginx für PHP mit Fast-CGI

Wenn wir bereits einen fertigen nginx am Laufen haben, sind nur wenige Zeilen in der Konfiguration zu ergänzen. Ansonsten lies bitte zuerst meine Anleitung zur Installation und Konfiguration des nginx.

Innerhalb des Vhosts, also innerhalb von server {} fügen wir eine neue Location-Direktive für PHP-Files hinzu:

   location ~ .*\.php$ {
    root /var/www/meinedomain.de/htdocs;
    fastcgi_pass 127.0.0.1:8088;
    fastcgi_index index.php;
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    include fastcgi_params;
   }


Hier darauf achten, das die Angaben in fastcgi_pass mit denen der vorhin konfigurierten übereinstimmen. include fastcgi_params inkludiert eine Datei, die bei der nginx-Installation enthalten ist, möchte Sie hier jedoch abbilden für den Fall das…

fastcgi_param QUERY_STRING $query_string;
fastcgi_param REQUEST_METHOD $request_method;
fastcgi_param CONTENT_TYPE $content_type;
fastcgi_param CONTENT_LENGTH $content_length;

fastcgi_param SCRIPT_NAME $fastcgi_script_name;
fastcgi_param REQUEST_URI $request_uri;
fastcgi_param DOCUMENT_URI $document_uri;
fastcgi_param DOCUMENT_ROOT $document_root;
fastcgi_param SERVER_PROTOCOL $server_protocol;

fastcgi_param GATEWAY_INTERFACE CGI/1.1;
fastcgi_param SERVER_SOFTWARE nginx/$nginx_version;

fastcgi_param REMOTE_ADDR $remote_addr;
fastcgi_param REMOTE_PORT $remote_port;
fastcgi_param SERVER_ADDR $server_addr;
fastcgi_param SERVER_PORT $server_port;
fastcgi_param SERVER_NAME $server_name;

# PHP only, required if PHP was built with --enable-force-cgi-redirect
fastcgi_param REDIRECT_STATUS 200;


Damit nginx auch beim Aufruf der Domain ohne Dateiname in der URL die Startseite als PHP ausführt, müssen wir zwei Parts in der bestehenden Konfiguration unter server {} anpassen bzw neu einsetzen:

Als erstes machen wir die Datei index.php zur ersten Wahl beim Aufruf ohne Dateiname:

index index.php index.html index.htm;


Alles andere was nicht gefunden wird, leiten wir ebenfalls auf index.php weiter:

# this sends all non-existing file or directory requests to index.php
if (!-e $request_filename) {
rewrite . /index.php last;
}


Das komplett Konfigfile könnte nun so aussehen:

server {
        # IP-Adresse und Port, an denen für Web-Zugriffe gelauscht wird
        listen     1.2.3.4:80;

        # Domains, auf die dieser Server hören soll
        server_name www.meinedomain.de meinedomain.de;

        # Hauptverzeichnis für Dokumente
        root         /var/www/meinedomain.de/htdocs;

        # Ort des Access-Logfiles
        access_log /var/www/meinedomain.de/logs/access_log vhosts;

        # Definition des Index-Files (Startseite, für Anfragen ohne Dateiname)
        index index.php index.html index.htm;;

        # Wenn Zugriff auf andere als Standarddomain,
        # auf diese per 301 permanent weiterleiten
        if ($host != 'www.meinedomain.de' ) {
         rewrite ^/(.*)$ http://www.meinedomain.de/$1 permanent;
        }

        # Für Bilder und einige andere Dateitypen Access-Log ausschalten und
        # Expire-Zeit auf 7 Tage erhöhen (sendet den entspr. Expire-Header)
        location ~* ^.+\.(js|css|jpg|jpeg|gif|png|pdf|zip|rar)$ {
         access_log off;
         expires     7d;
        }

        location / {
         # Nützlich für SSL und evtl. später hinzukommende Scriptsprachen
         proxy_set_header X-Real-IP $remote_addr;
         proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
         proxy_set_header Host $http_host;
         proxy_redirect off;

         # Wenn die angeforderete statische Datei existiert, diese ausliefern
         # ohne die anderen Regeln weiter unten zu beachten
         if (-f $request_filename) {
            break;
         }

         # this sends all non-existing file or directory requests to index.php
         if (!-e $request_filename) {
            rewrite . /index.php last;
         }
        }

        location ~ .*.php$ {
         root /var/www/meinedomain.de/htdocs;
         fastcgi_pass 127.0.0.1:8088;
         fastcgi_index index.php;
         fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
         include fastcgi_params;
         }
}


Jetzt heißt es den nginx mit /etc/init.d/nginx restart neu starten und PHP ist einsatzbereit.

WordPress kann nun ganz normal installiert und verwendet werden.

Insofern man ein Cache-Modul wie WP-Super-Cache nutzt, sollte man noch die entsprechenden RewriteRules für die statischen HTML-Dateien setzen. Für WP-Super-Cache beispielsweisse einfach folgende Zeilen innerhalb location / {} und vor der Einstellung für die .php-Dateien kopieren:

if (-f $document_root/cache$fastcgi_script_name) {
rewrite (.*) /cache$1 break;
}
if (-f $document_root/cache/$fastcgi_script_name/index.html) {
rewrite (.*) /cache/$1/index.html break;
}
if (-f $document_root/cache$fastcgi_script_name.html) {
rewrite (.*) /cache$1.html break;
}


Geschafft! Jetzt haben wir nginx mit PHP laufen und können uns über die bessere Performance freuen. Wenn du noch weitere Beispiele für Konfigurationen, auch für andere Sprachen und Einsatzmöglichkeiten suchst, empfiehlt sich ein Blick auf die Configuration-Seite von nginx.

Sicher folgen noch einige Artikel mehr über den nginx, um meine Begeisterung kund zu tun ;-) Solltest Du also Fragen, Wünsche, Vorschläge oder sonstiges haben, ab damit in die Kommentare, ich freue mich!

Credits:

Original-Foto Strap-On Video Rocket unter Creative Commons von jurvetson auf Flickr. Danke!

Ähnliche Artikel:

1. Nginx: Eine echte Apache Alternative! Vorteile, Installation und Konfiguration des Webservers unter Linux erklärt.

Marktanteile Top-Server über alle Domains Aug. 1995 – Feb. 2011. Quelle: netcraft.com

Seine weite Verbreitung, immerhin ist der Apache fast bei jedem Betriebssystem außer Windows dabei, die Anzahl der erhältlichen Erweiterungen und Module und die relativ leichte Konfiguration, auch in Massenhosting-Umgebungen, machen den Apache auch für Einsteiger zu einem Webserver der ersten Wahl. Wer jedoch mit viel Traffic zu tun hat und dabei eine serverseitige Skriptsprache wie PHP, Perl, Ruby oder ähnliches einsetzt, wird mit dem Apachen früher oder später an seine Grenzen stossen. Es ist mit Hilfe von Reduzierung auf wesentliche Module, Performance-Tuning und Tuning des Linux Systems natürlich sehr viel raus zu holen, doch irgendwann steht die Frage nach einer Alternative im Raum.

Der Webserver nginx

Hier war bis vor wenigen Jahren gerade im Linux-Bereich der Webserver lighttpd auf dem Weg eine echte Alternative zu werden, wurde jedoch im Jahr 2008 sehr schnell von einem Webserver Namens nginx überholt. nginx hat aktuell eine Verbreitung von 7.57% auf 21,570,463 Hosts. Tendenz startk steigend.
Der von Igor Sysoev ursprünglich für die russische Suchmaschine Rambler entwickelte nginx-Webserver, der auch als Reverse Proxy und E-Mail-Proxy verwendet werden kann, zeichnet sich durch seine hohe Performance und leichte Konfiguration aus. Gerade in Sachen Performance hat er den Apache schon einige Male in die Ecke verwiesen. nginx wird auch bereits von vielen High-Traffic-Seiten wie beispielsweise Golem.de, WordPress.com, t3n.de, GitHub und vielen weiteren mehr eingesetzt. Auch als zusätzliche Software zum Beispiel als Load-Balancer, Proxy, SSL-Proxy oder für das Ausliefern von reinen statischen Inhalten wie Grafiken, Stylesheets oder Videos eignet sich nginx durch seine kurzen Responce-Zeiten sehr gut.

nginx: Die Installation

Die Software zu installieren ist im Prinzip nicht weiter schwierig, sofern man Linux-Grundkenntnisse mitbringt. Download, Configure, Make, Install, Konfigurationsfiles anpassen und fertig ist die nginx-Installation. Doch eins nach dem anderen und auch für Einsteiger etwas langsamer erklärt. Ich möchte hier an einem Beispiel aufzeigen, wie man den nginx-Webserver installiert, konfiguriert und für das Ausliefern von statischen Webseiten vorbereitet.

Download des nginx

Die aktuelle stabile Version erhalten wir auf der Webseite des nginx. Aktuell ist die Version 0.8.54 vom 14.12.2010, die man unter folgenden URL downloaden kann:
http://nginx.org/download/nginx-0.8.54.tar.gz
Mit Linux macht man das am besten mit wget:

# wget http://nginx.org/download/nginx-0.8.54.tar.gz


Jetzt muß man den Tarball nur noch entpacken und es kann zur Installation übergehen.

# tar -xvzf nginx-0.8.54.tar.gz


Installation des nginx

Jetzt wechseln wir in das entpackte Verzeichnis. Um den nginx mit Standard-Modulen zu installieren reicht ein einfaches configure aus.

# cd nginx-0.8.54
# ./configure


Dies bereitet die Kompilierung des nginx in das Verzeichnis /usr/local/nginx mit Standard-Modulen wie dem HTTP-Kernmodul, HTTP-Upstreammodul, HTTP-Zugriffsmodul, HTTP-Authentifizierungsmodul und Fastcgi-Modul vor. Die Ausgabe der Zusammenfassung sollte so oder so ähnlich aussehen:

Configuration summary
+ using system PCRE library
+ OpenSSL library is not used
+ md5: using system crypto library
+ sha1 library is not used
+ using system zlib library

nginx path prefix: "/usr/local/nginx"
nginx binary file: "/usr/local/nginx/sbin/nginx"
nginx configuration prefix: "/usr/local/nginx/conf"
nginx configuration file: "/usr/local/nginx/conf/nginx.conf"
nginx pid file: "/usr/local/nginx/logs/nginx.pid"
nginx error log file: "/usr/local/nginx/logs/error.log"
nginx http access log file: "/usr/local/nginx/logs/access.log"
nginx http client request body temporary files: "client_body_temp"
nginx http proxy temporary files: "proxy_temp"
nginx http fastcgi temporary files: "fastcgi_temp"
nginx http uwsgi temporary files: "uwsgi_temp"
nginx http scgi temporary files: "scgi_temp"


Im nächsten Schritt heisst es kompilieren und installieren:

# make
# make install


Sollten diese beiden Make-Befehle ohne Fehler ausgeführt werden ist nginx nun unter dem Verzeichnis /usr/local/nginx installiert.

nginx: Die Konfiguration

Beginnen wir nun mit der Konfiguration. Im Prinzip können die Standard-Einstellungen übernommen werden, da sie für das Ausliefern von statischen Webseiten völlig ausreichend sind. Dennoch möchten wir hier einige Einstellungen variieren und jeweils noch die gewünschten Server bzw. Domains anlegen. Die Konfiguration befindet sich in der Datei /usr/local/nginx/conf/nginx.conf, die wir mit dem Editor unserer Wahl, in meine Fall der vi-Editor, öffnen:

# vi /usr/local/nginx/conf/nginx.conf

Globale Server-Einstellungen

An erster Stelle finden wir die globalen Einstellungen. Hier können Werte definiert werden, die für den gesamten Server gelten. Dazu gehören der User und die Gruppe unter der die Server-Prozesse laufen, Logfiles, Pidfile und Angaben zu Prozessen und MaxClients.

# User und Gruppe unter der der nginx läuft
user www www;

# Anzahl der Worker-Prozesse
worker_processes 2;

# Anzahl der maximalen Worker-Connections
events {
worker_connections 512;
}

# Ort und LogLevel der ErrorLog-Datei
error_log logs/error.log notice;

# Ort des Pidfiles
pid logs/nginx.pid;


Standardmässig läuft der nginx unter dem User nobody, was wir je nach Belieben anpassen können. Allerdings sollte man einen Werbserver niemals unter dem Benutzer root laufen lassen, um eventuellen Sicherheitslücken vorzubeugen.

Die Anzahl der Worker-Prozesse gibt an, wieviele Prozesse gestartet werden sollen. Der nginx startet einen Master-Prozess, der die Verwaltung übernimmt und die in der Konfiguration angegebene Anzahl von Worker-Prozessen. Diese Worker-Prozesse sind für die Verbindungen zum Benutzer und das Ausliefern der Webseite zuständig. 2 Worker-Prozesse sollten für den Anfang ausreichend sein.

Die Anzahl der Worker-Connections bestimmt die maximale Anzahl von gleichzeitigen Verbindungen, die ein Worker-Prozess verarbeiten kann. Aus beiden Werten von worker_processes und worker_connections ergibt sich hier also die maximale Anzahl von gleichzeitigen Verbindungen für den gesamten Webserver, der so genannten auch aus der Apache-Konfiguration bekannten Variable MaxClients. Die Formel hierfür ist

max_clients = worker_processes * worker_connections

In unserem Fall 2 * 512 = 1024. 1024 Verbindungen sollten für den Anfang mehr als ausreichend sein und können bei Ressourcenmangel ruhig auch bis 250 minimiert werden.

Den Ort und LogLevel der ErrorLog-Datei, sowie den Ort des Pidfiles können wir getrost so übernehmen.

HTTP Server-Einstellungen

Jetzt kommen wir zur Konfiguration des HTTP-Services und der einzelnen Server. Die Standard-Einstellungen sollten angepasst werden und wurden von mir für optimale und performante Auslieferung mit Hilfe von Gzip, Cache-Einstellungen usw. optimiert. Nehmen wir als Beispiel die IP 1.2.3.4 und eine Domain Namens www.meinedomain.de mit statischen HTML-Seiten, Bildern, Stylesheets und einigen Download-Dateien im Verzeichnis /var/www/meinedomain.de/htdocs, welches natürlich vorhanden sein sollte. Auch an SEO sollten wir gleich denken, die Domain wirklich nur unter einer Domain erreichbar machen und alles andere auf diese per 301-Weiterleitung weiterleiten.

http {
    # die Konfiguration der Content-Typen aus conf/mime.types inkludieren
    include     mime.types;

    # Der Standard-Content-Typ
    default_type application/octet-stream;

    # Support für größere Dateien
    sendfile     on;

    # HTTP Response-Header in einem Paket senden
    tcp_nopush     on;

    # Sekunden, in denen auf eine erneute Verbindung vom
    # gleichen Client gewartet wird
    keepalive_timeout 65;

    # Disable Nagle's buffer algorithm
    tcp_nodelay        on;

    # Gzip aktivieren, sendet komprimierte Daten zum Client
    gzip on;
    gzip_comp_level 2;
    gzip_proxied any;
    gzip_types     text/plain text/css application/x-javascript text/xml application/xml application/xml+rss text/javascript;

    # Definition des Logfile-Formats
    log_format vhosts '$http_host $remote_addr - $remote_user [$time_local] '
                             '"$request" $status $body_bytes_sent '
                             '"$http_referer" "$http_user_agent"';

# VHost-Konfiguration
server {
        # IP-Adresse und Port, an denen für Web-Zugriffe gelauscht wird
        listen     1.2.3.4:80;

        # Domains, auf die dieser Server hören soll
        server_name www.meinedomain.de meinedomain.de;

        # Hauptverzeichnis für Dokumente
        root         /var/www/meinedomain.de/htdocs;

        # Ort des Access-Logfiles
        access_log /var/www/meinedomain.de/logs/access_log vhosts;

        # Definition des Index-Files (Startseite, für Anfragen ohne Dateiname)
        index index.html;

        # Wenn Zugriff auf andere als Standarddomain,
        # auf diese per 301 permanent weiterleiten
        if ($host != 'www.meinedomain.de' ) {
         rewrite ^/(.*)$ http://www.meinedomain.de/$1 permanent;
        }

        # Für Bilder und einige andere Dateitypen Access-Log ausschalten und
        # Expire-Zeit auf 7 Tage erhöhen (sendet den entspr. Expire-Header)
        location ~* ^.+\.(js|css|jpg|jpeg|gif|png|pdf|zip|rar)$ {
         access_log off;
         expires     7d;
        }

        location / {
         # Nützlich für SSL und evtl. später hinzukommende Scriptsprachen
         proxy_set_header X-Real-IP $remote_addr;
         proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
         proxy_set_header Host $http_host;
         proxy_redirect off;

         # Wenn die angeforderete statische Datei existiert, diese ausliefern
         # ohne die anderen Regeln weiter unten zu beachten
         if (-f $request_filename) {
            break;
         }

         # index.html für Unterverzeichnisse
         if (-f $request_filename/index.html) {
            rewrite (.*) $1/index.html break;
         }
        }
}
}


Die Konfiguration besteht aus dem Part http mit Definitionen für diesen Service. Hier wird zuerst die Mime-Konfiuration geladen, Einstellungen zum Connection-Verhalten gesetzt, das Gzip-Modul zum komprimieren der Daten aktiviert und die Definition des Logfile-Formates vorgenommen. Weiter finden wir innerhalb des http-Parts den server-Part, die Konfiguration der einzelnen Websites, auch genannt VHosts. Ich habe auch hier die einzelnen Direktiven oben kommentiert, weshalb ich auf weitere detailiertere Beschreibung verzichte. Im Prinzip ist alles selbsterklärend. Will man weitere Domains bzw. Server hinzufügen muß man lediglich den Part server {} kopieren. Dabei ist darauf zu achten, daß jede Konfiguration nacheinander innerhalb von http {} steht. Ab zwei Servern lohnt es sich schon, für jeden Server ein eigenes Konfigurationsfile anzulegen. Hierfür erstellt man innerhalb des conf-Verzeichnisses ein Unterverzeichnis, zum Beispiel “sites” und inkludiert die darin enthaltenen Files einfach innerhalb des http-Parts:

include /usr/local/nginx/conf/sites/*;


Jetzt kann man sich für jede Domain ein eigenes Konfigurationsfile anlegen, was wesentlich übersichtlicher ist.

Das nginx Startscript

Was uns jetzt noch fehlt ist, den nginx das erste Mal zu starten. Hierfür benötigen wir ein sogenanntes Startskript, welches wir z.B. hier für Ubuntu bekommen und unter /etc/init.d/nginx ablegen. Alternativ kann es hier kopiert und für evtl. andere Distributionen angepasst werden:

#!/bin/sh

#This is a start script for nginx. Tested on Unbuntu Edge.
#Should work on Ubuntu, Debian and probably a few other Linux distros.
#Change DAEMON and CONFIG_FILE if neccessary

PATH=/sbin:/bin:/usr/sbin:/usr/bin

#Location of nginx binary. Change path as neccessary
DAEMON=/usr/local/nginx/sbin/nginx
#Location of configuration file. Change path as neccessary
CONFIG_FILE=/usr/local/nginx/conf/nginx.conf

DAEMON_OPTS="-c $CONFIG_FILE"
NAME=nginx
DESC="web server"
PIDFILE=/var/run/$NAME.pid
SCRIPTNAME=/etc/init.d/$NAME

#only run if binary can be found
test -x $DAEMON || exit 0

set -e

#import init-functions
. /lib/lsb/init-functions

case "$1" in
start)
log_daemon_msg "Starting $DESC" $NAME
if ! start-stop-daemon --start --quiet\
--pidfile $PIDFILE --exec $DAEMON -- $DAEMON_OPTS ; then
log_end_msg 1
else
log_end_msg 0
fi
;;
stop)
log_daemon_msg "Stopping $DESC" $NAME
if start-stop-daemon --quiet --stop --oknodo --retry 30\
--pidfile $PIDFILE --exec $DAEMON; then
rm -f $PIDFILE
log_end_msg 0
else
log_end_msg 1
fi
;;
reload)
log_daemon_msg "Reloading $DESC configuration" $NAME
if start-stop-daemon --stop --signal 2 --oknodo --retry 30\
--quiet --pidfile $PIDFILE --exec $DAEMON; then
if start-stop-daemon --start --quiet \
--pidfile $PIDFILE --exec $DAEMON -- $DAEMON_OPTS ; then
log_end_msg 0
else
log_end_msg 1
fi
else
log_end_msg 1
fi
;;
restart|force-reload)
$0 stop
sleep 1
$0 start
;;
*)
echo "Usage: $SCRIPTNAME {start|stop|restart|reload|force-reload}" >&2
exit 1
;;
esac

exit 0


Jetzt noch mit chmod das Ausführen der Datei erlauben:

# chmod 700 /etc/init.d/nginx

Nun können wir uns freuen und den nginx das erste Mal starten:

# /etc/init.d/nginx start

Ist alles korrekt und das Konfigurationsfile ohne Fehler, sollte der nginx starten und die Webseite unter der konfigurierten Domain erreichbar sein.

nginx Autostart

Damit der nginx auch beim nächsten Server-Neustart automatisch startet, benötigen wir einen Eintrag bzw. einen symbolischen Link im Runlevel-Startverzeichnis, hier als Beispiel für Ubuntu:

ln -s /etc/init.d/nginx /etc/rc2.d/S99nginx

Somit startet nginx beim nächsten Neustart des Servers im Runlevel 2 automatisch. Falls ein anderes Runlevel läuft (ersichtlich mit dem Befehl “runlevel”), einfach den Link im jeweiligen Verzeichnis erstellen.

Und nun: Viel Spaß mit nginx!

Das wars! Ich hoffe ich konnte Dir hier einen kleinen Einstieg in nginx vermitteln. Ein Artikel zur Verwendung von PHP und Installation von WordPress folgt demnächst. Bei Fragen, Verbesserungen oder Angregungen freue ich mich über Kommentare.

Weiterführende Links

- nginx-Webseite
- nginx-Wiki
- nginx bei Wikipedia
- nginx bei Ubuntu

Ähnliche Artikel:

1. WordPress langsam? PHP und WordPress schneller machen mit Nginx und Fast-CGI!

1. Ubuntu Netbook Edition downloaden
http://www.ubuntu.com/netbook/get-ubuntu/download

Das war’s schon. Ansich wirklich kein Thema, wenn man sowas noch nie gemacht hat, ist so eine Kurzanleitung sicher ganz hilfreich.

Da die Funktions-Tasten (Screen-Beleuchtung, Lautstärke etc.) von Anfang an bei Ubuntu nicht funktionieren, hat mir diese Anleitung geholfen sie in Gang zu bekommen.

Viel Spaß!

No related posts.

Schnell merkt man das die Größe der Festplatte nicht mehr ausreicht und der freie Speicherplatz wird immer geringer. Was also tun? Zum Glück kann man ein Loop Device problemlos vergrössern. Die folgende Anleitung beschreibt, wie man auf Linux-Systemen ein solches Loop Disk Image vergrössern kann, sofern man das ext2 oder ext3 Filesystem nutzt (Unter ext4 sollte dies ebenso laufen, wurde allerdings noch nicht getestet).

1. Virtuellen Server stoppen, der das zu vergrößernde Loop Device nutzt

2. Falls genügend Platz vorhanden ist, Backup des aktuellen Loop Devices erstellen mit:

# cp loop_image_file loop_image_file.backup

3. Folgenden Befehl zum Vergrössern des Loop Devices bzw. der Loop Disk Image nutzen:

# dd if=/dev/zero bs=1024k count=1024 >> loop_image_file

Anstatt “loop_image_file” den Pfad zu Eurem Loop Disk Image nutzen. der Befehl fügt dem Image 1 GB Platz hinzu. Möchte man mehr Platz hinzufügen, ändert man einfach den count-Paremeter entsprechend des gewünschten Platzes. Unbedingt sicher gehen, das der zweifache (also hinzufügende) Redirector >> genutzt wird und nicht der einfache >. Sonst würde das File einfach überschrieben werden (deshalb auch zur Sicherheit unser Backup :-).

4. Plattencheck auf das neue vergrösserte Filesystem ausführen:

# e2fsck -f loop_image_file

5. Filesystem mit folgendem Befehl vergrössern bzw. auf die Grösse anpassen

# resize2fs loop_image_file

6. Virtuellen Server starten.

Jetzt sollte auf dem VServer beim Ausführen von “df” mehr Platz zur Verfügung stehen.

Das ist eine Übersetzung des Original-Posts "Howto: Resize Xen Loop Disk Image".

No related posts.

Crontab

Crontab wird die Tabelle genannt, in der die einzelnen Cronjobs definiert und konfiguriert werden. Die Tabelle enthält pro Zeile den Zeitpunkt und die Befehlsfolge, die ausgeführt werden soll. Der Begriff Crontab setzt sich aus dem griechischen Chronos (Zeit) und lateinischen Tabula (die Tafel, das Brett) zusammen.

Gleichzeitig ist crontab auch das Programm, mit dessen Hilfe man die Crontabs bearbeiten kann. Um die Contab zu bearbeiten, muß folgender Befehl eingegeben werden:

crontab -e

Crontab Syntax

Jeder Cronjob hat folgendes Format:

* * * * * auszuführender Befehl
┬ ┬ ┬ ┬ ┬
│ │ │ │ │
│ │ │ │ └──── Wochentag (0-7, Sonntag ist 0 oder 7)
│ │ │ └────── Monat (1-12)
│ │ └──────── Tag (1-31)
│ └────────── Stunde (0-23)
└──────────── Minute (0-59)


Ein Stern * bedeutet Ausführung wird immer erfolgen, also zu jeder Minute, jeder Stunde, jedem Tag, jedem Monat oder jedem Wochentag. Um die einzelnen Stellen auseinander zu halten, hilft folgendes Diagram:

1 2 3 4 5 Befehl

1 = Minute (0-59)
2 = Stunde (0-23)
3 = Tag (0-31)
4 = Monat (1-12)
5 = Wochentag (0-7, Sonntag ist 0 oder 7)
Befehl = Der auszuführende Befehl.


Für die ersten fünf Stellen, also die Zeiwerte sind folgende Optionen zusätzlich möglich:

* = Ausführung immer (zu jeder…)
*/n = Ausführung aller n
n,x,y = Ausführung um/am n, x und y

Cronjob Beispiele

Um zum Beispiel jede Nacht um 5 Uhr morgens das Backup auszuführen, würde man den Cronjob folgendermaßen anlegen:

0 5 * * * /usr/bin/backup.sh


Einen Sound alle 10 Minuten Abzuspielen könnte wie folgt aussehen:

*/10 * * * * /usr/bin/play_sound.sh


Eine Erinnerungsmail um 8 und um 17 Uhr zu verschicken geht z.B. so:

0 8,17 * * * /usr/bin/send_reminder_mail.sh


Ausgabe der Cronjobs

Die Ausgabe der Cronjobs wird standardmässig per Mail an den jeweiligen System-User der den Cronjob eingerichtet hat gesendet. Um dies zu unterdrücken, könnte man die Ausgabe in eine Datei umleiten oder mit Umleitung zu /dev/null komplett verwerfen:

Cronjob-Ausgabe in Logfile umleiten

0 8,17 * * * /usr/bin/script.sh >>/var/log/cron/send_reminder_mail 2>&1


Cronjob-Ausgabe verwerfen

0 8,17 * * * /usr/bin/script.sh >/dev/null 2>&1


2>&1 bedeutet, das sowohl die normale Ausgabe als auch Fehler in die vorher angegebene Datei umgeleitet werden.

Cronjob-Dateien und Verzeichnisse

Zusätzlich zum crontab-Befehl gibt es je nach Distribution Dateien, die systemweite Crontabs beinhalten und nur durch den User root bearbeitet werden können:

/etc/crontab

Die System-Crontab-Datei, in der zusätzlich noch ein System-Benutzer, der den Befehl ausführen soll, mit angegeben werden muß:

1 2 3 4 5 Benutzer Befehl

1 = Minute (0-59)
2 = Stunde (0-23)
3 = Tag (0-31)
4 = Monat (1-12)
5 = Wochentag (0-7, Sonntag ist 0 oder 7)
Benutzer = Benutzername des Benutzers, unter dem der Befehl ausgeführt wird.
Befehl = Der auszuführende Befehl.


Beispiel:
0 8,17 * * * root /usr/bin/script.sh >>/var/log/cron/send_reminder_mail 2>&1
0 3 * * * wwwrun /usr/bin/webjobs_nighly.sh >>/var/log/cron/send_reminder_mail 2>&1


/etc/cron* Verzeichnisse

Eine weitere Möglichkeit Cronjobs anzulegen sind die Verzeichnisse unter /etc/cron*, in denen alle enthaltenen Dateien zum bestimmten Zeitpunkt ausgeführt werden. Die Dateien im Einzelnen

/etc/cron.d/ = Erweiterungen zur /etc/crontab-Datei, gleiche Syntax.
/etc/cron.daily/ = Einmal irgendwann täglich.
/etc/cron.hourly/ = Einmal irgendwann stündlich.
/etc/cron.monthly/ = Einmal irgendwann monatlich.
/etc/cron.weekly/ = Einmal irgendwann wöchentlich.

Die letzten vier werden oft genutzt, wenn ein Job in einem bestimmten Interval erledigt werden muß, der genaue Zeitpunkt hierfür aber unerheblich ist.

Crontab und gut?

Ich hoffe, ich konnte einen kleinen Einblick in die Cronjobs unter Linux geben und dem ein oder anderen bei der Syntax behilflich sein. Dieser Artikel entsteht auch mit etwas Eigennutz, da ich auch oft überlegen muß, wie die genaue Reihenfolge in der Crontab nun ist. Es gibt natürlich noch eine Menge anderer Tools wie at, anacron, fcron und so weiter. Cronjob hat für mich jedoch sehr zuverlässig gearbeitet, weshalb ich andere Tools noch nicht in Betracht gezogen habe.

Let the crons work!

No related posts.

3 Unix commands for finding performance problems

Ähnliche Artikel:

1. Nginx: Eine echte Apache Alternative! Vorteile, Installation und Konfiguration des Webservers unter Linux erklärt.

Ohne Worte. Via Caschy.

No related posts.

bash: line 1: rsync: command not found
rsync: connection unexpectedly closed (0 bytes received so far) [receiver]
rsync error: remote command not found (code 127) at io.c(453) [receiver=x.x.x]


Hat man keinen Root-Zugriff auf dem Remote Server, so stellt dies kein Problem dar. Rsync kann auch ganz leicht im eigenen Home-Verzeichnis installiert werden. Hierfür geht man einfach auf die rsync-Webseite unter http://samba.anu.edu.au/rsync/ und lädt sich die aktuelle rsync-Version (in diesem Beispiel 3.0.6) herunter, entpackt und kompiliert diese:

wget http://samba.anu.edu.au/ftp/rsync/src/rsync-3.0.6.tar.gz
tar -xvzf rsync-3.0.6.tar.gz
cd rsync-3.0.6
./configure --prefix=/pfad/zu/deinem/homedir
make


Und schon hat man eine lauffähige rsync-Version installiert und muß nun noch in der .bashrc oder .cshrc den entsprechenden Pfad hinzufügen:

vi ~/.bashrc


Folgende Zeile einfügen:

export PATH=$PATH:/pfad/zu/deinem/homedir/rsync-3.0.6

Anstatt /pfad/zu/deinem/homedir natürlich den Pfad zu deinem Homeverzeichnis.

Jetzt kann man ganz normal vom entfernten Rechenr den rsync starten

rsync -e ssh -avzr remoteserver:~/wasauchimmer/ /lokaler/pfad/wasauchimmer/

Das funktioniert natürlich nicht nur mit rsync, sondern auch mit anderen Tools, die ansich kein Root-Recht zum installieren benötigen.

No related posts.

Hast du auch lustige Befehle?
Bitte schicke Sie mir oder schreib Sie in die Kommentare, ich werde Sie dann der Liste hinzufügen. Vielen Dank!

Liste lustiger Linux/Unix-Kommandos

Durch die Blume:

bash:~# netstat -tulpen

Wenn man hungrig ist:

bash:~# ps haxen

Linux will keine Liebe machen:

bash:~# make love
make: *** No rule to make target `love'. Stop.

Krieg zum Glück auch nicht:

bash:~# make war
make: *** No rule to make target `war'. Stop.

Ohne Widerrede dagegen wird folgendes ausgeführt:

bash:~# touch me

Versaut geht es gar nicht:

bash:~# %blow
-bash: fg: %blow: no such job

Keine Anleitung für Frauen.

bash:~# nice man woman
No manual entry for woman

Funny

bash:~# \(-
-bash: (-: command not found

Ne Runde schlafen:

bash:~# while true; do sleep 1; done

Und weg:

bash:~# ex - und hopp
2 Dateien zur Bearbeitung

Einfach mal Klamotten zählen:

bash:~# socklist

Linux ist auch kein Geldesel:

bash:~# find money
find: money: No such file or directory

Wichtige Befehlsfolge:

unzip, strip, touch, finger, grep, mount, fsck, more, yes, fsck, fsck, fsck, umount, sleep

Quellen:
http://www.linuxfocus.org/Deutsch/July1999/article104.html
http://www.tbi.univie.ac.at/~ronke/FUN/unix.html

No related posts.

Oft ist es notwendig aus einem System-Logfile, Daten wie Befehle, Dateinamen, User-Agents, Zeiten oder was auch immer zu zählen, zu summieren und zu sortieren. Möchte man zum Beispiel wissen, welcher Befehl auf einem Webserver am meissten aufgerufen wurde, reicht ein Einzeiler:

cat access_log | awk '{print $6}' | sort | uniq -c | sort -nr | less


Was hier passiert, möchte ich kurz erklären:

cat access_log
Hier öffnen wir die Datei access_log und leiten den Inhalt an den Standard-Output – hier unsere Konsole – zur Ausgabe weiter.

awk '{print $6}'
Mit Awk können wir uns einfach Teile einer Ausgabe aus einem Text herausfiltern. Hier die 6. Stelle – der Befehl. Das Standard-Trennzeichen von awk ist das Leerzeichen, was aus diesem Grund nicht mit angegeben werden muss.

sort
Diese Befehl sortiert die aktuelle Ausgabe.

uniq -c
Hier werden gleich zwei Sachen erledigt. Es werden doppelte Einträge entfernt und gleichzeitig die Anzahl der Vorkommnisse als Prefix vor jede Zeile gesetzt.

sort -nr
Sortiert diese Ausgabe nochmals, jetzt jedoch nach Nummern und rekursiv, so dass der Eintrag mit dem meißten Ergebnissen oben steht.

less
Hier kann wahlweisse auch tail verwendet werden. Sollte klar sein. Less lässt uns die ersten Zeilen in normaler Geschwindigkeit lesen, in dem es die Ausgabe nach vollem Bildschirm anhält.

Die Ausgabe des ganzen Befehles sollte nun ungefähr so aussehen:

528162 "GET
8583 "POST
242 "HEAD
15 "OPTIONS
2 "PUT


Wir können hiermit nun beliebig benötigte Daten zählen und uns schnell einen Überblick über die Anzahl der jeweiligen Vorkommnisse anzeigen lassen. Eine kleine Linux-Live-Statistik sozusagen.

Ähnliche Artikel:

1. Nginx: Eine echte Apache Alternative! Vorteile, Installation und Konfiguration des Webservers unter Linux erklärt.