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!

No related posts.

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

No related posts.

Auch wenn die Zeichen aufgrund mangelnder Breite in meinem Layout umbrechen, sind dies alles Einzeiler ;-)

Zufallsstring mit PHP – Einzeiler

Variante 1

echo substr(str_shuffle("23456789abcdefghjkmnopqrstuvwxyzABCDEFGHJKLMNPQRSTUVWXYZ"), 0, 8);

Ja, ich kann zählen und das Alphabet auch. Unnötige und für Passwörter ungeeignete Zeichen habe ich hier weg gelassen.

Variante 2

Wer es noch kürzer braucht, kann auch md5 nehmen. Danke an Jonathan für den Hinweis. Aber Achtung, hier sind nur die Zeichen 0-9 und a-f enthalten.
echo substr(md5(time()),0,8);
Du hast auch schöne Einzeiler, die richtig Sinn und das PHP-Entwickler-Leben leichter machen? Bitte ab damit in die Kommentare oder per E-Mail an mich. Danke!

No related posts.

1. .html on PAGES

Ich finde wichtig, das man alle Dateiendungen – sofern man welche nutzt – auf einer Webseite einheitlich hat. Da ich bei Posts die Endung .html bevorzuge, sollten auch die Seiten diese Endung haben dürfen. Man sagt es sei auch wichtig für Google.

2. All in One SEO Pack

Das ultimative SEO-Plugin. Hier kann man eigentlich alles einstellen, was man an SEO benötigt. Es gibt sicher einige andere oder bessere, hab mich aber auf dieses eingeschossen.

3. Antispam Bee

Verhindert Spam in Kommentaren und Pings sehr zuverlässig. Ziehe ich Askimet unbedingt vor, da es dem deutsche Datenschutz gerecht wird (falls das möglich ist:) und man hier keinen API-Key benötigt und es genauso gut wenn nicht besser läuft als Askimett.

4. Delete-Revision

WordPress legt bei jedem Speichern eine Version das Posts an, d.h. pro Speichern ein Datensatz in der Datenbank. Das wird natürlich bei vielen Artikeln auch ohne akutem Zucken auf den Speichern-Button eine Menge an Daten, die später so nicht mehr benötigt werden. Das Löschen der nicht benötigten Versionen bzw. Revisionen erledigt dieses Müllschlucker-Plugin “Delete-Revision” zuverlässig. Yamyam!

5. Permalink Redirect

Noch ein SEO-Plugin. Entfernt alle unnötigen GET-Parameter bzw. Attribute und URL-Parts (the whole Crap!) von der URL und leitet auf die eigentliche URL weiter. Verhindert Duplicate Content. Wichtig für Google und SEO, also ein Muss.

6. Permalinks Moved Permanently

Ändert man mal den Permalink, also die URL eines Posts, muß die alte natürlich auf die neue weitergelietet werden. Das erledigt dieses nette Plugin.

7. Robots Meta

Ermöglicht pro Artikel oder Seite die Einstellung des Robots-Meta-Tag’s. Hiermit lässt sich bestimmen, welche Seiten oder Artikel im Google-Index indexiert werden sollen und wo Links verfolgt werden dürfen. Sehr nützlich für den SEO-Steuermann.

8. SEO Friendly Images

Fügt automatische Alt- und Title-Attribute zu Bildern hinzu. Genial, wenn man mit Bildern in Google gefunden werden will. Spart ‘ne Menge Arbeit.

9. WordPress Database Backup

Hier kann man sich das Backup der WP-Datenbank in einem bestimmten Interval, beispielsweisse täglich, per Mail zusenden lassen, auf einem Rechner oder in einem Verzeichnis speichern lassen. Security first!

10. WP Super Cache

Cached alle Inhalte als statische HTML-Seiten, was die Ladezeit um einiges veringert. Dauer und Regeln lassen sich beliebig anpassen.

11. Yet Another Related Posts Plugin

Verlinkt passende Artikel untereinander. Klasse Plugin und Algorithmus! Bringt nicht nur dem benutzer viel Komfort, sondern auch Google und SEO.

Das ist sie also, meine Liste der Plugins die ich aktuell und aus den letzten 6 Jahren Erfahrung am wichtigsten erachte.

Nein, ein Plugin zur Integration von Twitter oder Facebook hab ich nicht, das hab ich bisher lieber selbst gemacht, da die meissten das Design zerschossen haben und das Fixing zu aufwendig gewesen wäre oder mir eben benötigte Features fehlten. Vielleicht findet sich aber noch ein brauchbares.

Wie sieht es bei euch aus, was habt Ihr unter der Haube? Oder haltet Ihr das ein oder andere Plugin für Käse?

No related posts.

WordPress hat eine riesige Community, viele Nutzer und einen hohen Bekanntheitsgrad. Wenn man beispielsweisse ein WordPress-Plugin schreiben möchte, kann man sich durch schon vorhandene Plugins wuseln und von bestehendem Code Anregungen holen und evtl. sogar Teile verwenden – natürlich nur unter Einhaltung des Copyrights. Möchte man dieses Plugin verkaufen, hat man mit WordPress eine sehr große und täglich wachsende Menge an potenziellen Kunden. Ein weiterer Vorteil ist die große Menge an Einsatzgebieten von WordPress. WordPress kann als Blog verwendet werden, als normale Webseite mit oder ohne CMS, als Forum, als Gallery, als Community und und und. Das meiste natürlich mit fertigen Plugins. Warum also etwas eigenes entwickeln, wenn es alles schon gibt? Zumal ja fast jede Webseite sowieso einen Blog und somit auch WordPress hat und benötigt. Die Nachteile bei WordPress liegen ganz klar bei der mangelnden Performance und – für mich persönlich – an der etwas veralteten Scriptsprache PHP. Logisch kann man die Performance mit ein paar Tricks, passenden Plugins und besserer Server-Hardware tunen, dennoch ist WordPress den eigenen Lösungen in PHP oder Ruby On Rails klar unterlegen. Gerade wenn der Content in der Datenbank wächst – und ich meine hiermit eine Menge von 1000+ Artikeln – wird WordPress zur Slow-Motion-Bremse.

Ruby on Rails ist hingegen, wenn man es richtig anstellt, ein richtiger Turbo und Spaßfaktor. Das Coden in Ruby macht einfach einen Riesenspaß, was die Produktivität um einiges steigert. Das DRY-Prinzip richtig angewendet, muß hier bei gleicher Funktionalität auch weniger Code geschrieben werden. Man kann also sagen, das mit Rails einfacher in hoher Qualität Software entwickelt werden kann. Ebenso gibt es für fast alle Belange fertige Plugins und Librarys, die man beliebig erweitern und verwenden kann. Die Menge der Entwickler ist zwar hoch und wird immer höher, aber es gibt lange noch nicht so viele wie für WordPress. Ruby On Rails wird eher von Profis eingesetzt, Hobby-Entwickler hingegen greifen schnell zu PHP und WordPress. Desweiteren benötigt man für Rails immer eine gesonderte Server-Konfiguration, weshalb die meisten bekannten Webhoster hier ausscheiden. Noch ein negativer Punkt ist, das es für Rails keine gute Blog-Software gibt. Zwar sind einige wenige Versuche vorhanden, die an WordPress jedoch bei weitem nicht heranreichen. Schade eigentlich, eine gute Blog-Software in Ruby wär was feines und sicher ein schönes Projekt.

Also bleibt ganz klar eines zu sagen. Möchte man Software vielen Millionen Menschen verfügbar machen oder womöglich verkaufen, empfiehlt sich der Einsatz von WordPress. Legt man jedoch Wert auf Performance, Spaß beim Coden und hat Profis zur Hand, ist Rails eine gute Wahl. Also ist meine erste Überlegung in der Richtung ab jetzt: “Möchte ich die Software nur für mich oder auserwählte Kunden nutzen oder an tausende Kunden verkaufen?”.

Was meint Ihr dazu? Lieber WordPress oder Rails bzw. anderen Sprachen oder Frameworks? Freu mich über Kommentare!

No related posts.

Was aber, wenn wir dynamische Inhalte darstellen wollen und gar nicht wissen wieviel Inhalt wir pro Element bekommen. Bei Texten, längeren Namen or whatever aus einer Datenbank ist dies oft der Fall. Durch den unterschiedlich langen Inhalt werden die Elemente nun dementsprechend anders hoch dargestellt. Das sieht bei Elementen die wir nebeneinander zeigen möchten meistens ziemlich doof aus.

Hier kann das Javascript-Framework jQuery helfen. jQuery bietet eine Funktion mit dem Namen .height(), die uns die Höhe eines Elements setzen oder auslesen kann. Hier wird nicht einfach die CSS-Eigenschaft height ausgelesen, sondern die fertig gerenderte Höhe des Elements. So braucht man mit jQuery nicht viel Mühe, um alle gewünschten Elemente zu durchlaufen, das höchste zu bestimmen und alle Elemente auf eben diese Höhe anzupassen.

Der HTML-Code

Gehen wir von folgendem HTML-Code aus. CSS habe ich zu besseren Ansicht inline definiert:

<div class="autoheight" style="float: left; width: 200px; background-color: lightgreen;">
Hier steht Inhalt, der in der Länge bzw. Höhe variabel sein kann. Zum testen schreib ich hier irgendwas rein.
</div>
<div class="autoheight" style="float: left; width: 200px; background-color: orange;">
Hier steht Inhalt, der in der Länge bzw. Höhe variabel sein kann. Zum testen schreib ich hier irgendwas rein.
Hier steht Inhalt, der in der Länge bzw. Höhe variabel sein kann. Zum testen schreib ich hier irgendwas rein.
Hier steht Inhalt, der in der Länge bzw. Höhe variabel sein kann. Zum testen schreib ich hier irgendwas rein.
</div>
<div class="autoheight" style="float: left; width: 200px; background-color: mediumblue;">
Hier steht Inhalt, der in der Länge bzw. Höhe variabel sein kann. Zum testen schreib ich hier irgendwas rein.
Hier steht Inhalt, der in der Länge bzw. Höhe variabel sein kann. Zum testen schreib ich hier irgendwas rein.
</div>

Das Javascript mit jQuery

Zuerst müssen wir die Höhe des höchsten Div’s ausfindig machen. Wir gehen am besten alle Elemente durch und bestimmen so das höchste von allen. Dazu müssen wir uns den höchsten Wert einfach nur merken und immer vergleichen:

/* Variable zum Merken der maximalen Höhe */
var max_height = 0;

/* alle Elemente mit der CSS-Klasse "autoheight" durchlaufen */
$('.autoheight').each(function(e) {

  /* Höhe des aktuellen Elements */
  h = $(this).height();

  /* Wenn Höhe erfolgreich bestimmt werden konnte */
  if(typeof(h) != "undefined") {

        /* Wenn aktuelle Höhe gösser unserer maximalen, Höhe merken */
        if(h > max_height) {
                max_height = h;
        }
  }
});

Nun müssen wir alle anderen Elemente höher bekommen. Wenn wir die maximale Höhe bestimmen konnten, wenden wir diese jetzt einfach auf alle Elemente an:

if(max_height > 0) {
 $('.autoheight').height(max_height);
}

Das ganze Javascript sieht dann so aus:

var max_height = 0;
$('.autoheight').each(function(e) {
  h = $(this).height();
  if(typeof(h) != "undefined") {
        if(h > max_height) {
                max_height = h;
        }
  }
});
if(max_height > 0) {
 $('.autoheight').height(max_height);
}

Das fertige Ergebnis als Beispiel

Das oben beschriebene Beispiel sollte dann in etwa so aussehen:

Boxen original

No related posts.

require 'net/http'

def check_for_notfound(url)
  uri = URI.parse(url)
  response = Net::HTTP.get_response(uri)

  case response
    when Net::HTTPNotFound:
      return true
    when Net::HTTPRedirection:
      puts check_for_notfound('http://' + uri.host + response['location'])
    else
      return nil
  end
end

File.open(ARGV[0]) do |f|
  f.each do |line|
    result = check_for_notfound(line)
    if !result.nil? and result == true
     puts line
    end
  end
end

Wer ein besseres Script hat oder etwa eine Möglichkeit weiß, wie man dies mit wget lösen kann, bitte einen Kommentar hinterlassen. Danke!

Update:

Wie ich Dank eines anderen Blogs erfahren konnte, ist das mit wget natürlich auch schnell und sogar mit einem Einzeiler lösbar:

wget -r -nd --delete-after --no-parent --no-cookies --input-file=urls.txt

Ob man nun Ruby oder wget nutzt, hängt ganz davon ab, ob man es in eine Software integrieren möchte oder ob es nur einem schnellen administrativen Todo dienen soll.

No related posts.

Eine einfache Webseite ist in Sinatra leicht geschrieben:

require 'rubygems'
require 'sinatra'

get '/hi' do
"Hello World!"
end

Mehr Infos unter http://www.rubyinside.com/sinatra-1-0-released-3162.html.

No related posts.

Ein Problem entsteht allerdings, wenn man eigene Verzeichnisse für die Sessionfiles definiert. Hier werden die Files dann nicht gelöscht und bleiben bestehen, was das Verzeichnis – je nach Traffic – schnell auf ein paar Tausende Dateien anwachsen lassen kann.

Um die Garbage Collection in PHP zu aktivieren, muss folgender Eintrag in der php.ini (für Apache unter /etc/php5/apache2/php.ini) geändert werden:

VORHER

;session.gc_probability = 0
session.gc_divisor = 100

NACHHER

session.gc_probability = 1
session.gc_divisor = 100

Diese Änderung bewirkt, das bei jedem hundertsten Start einer Session die Sessionfiles gelöscht werden.

Zusätzlich muss dann noch der Cronjob deaktiviert werden. Hierzu einfach /etc/cron.d/php5 mit dem Editor deiner Wahl bearbeiten und die letzte Zeile auskommentieren:

# /etc/cron.d/php5: crontab fragment for php5
# This purges session files older than X, where X is defined in seconds
# as the largest value of session.gc_maxlifetime from all your php.ini
# files, or 24 minutes if not defined. See /usr/lib/php5/maxlifetime

# Look for and purge old sessions every 30 minutes
#09,39 * * * * root [ -x /usr/lib/php5/maxlifetime ] && [ -d /var/lib/php5 ] && find /var/lib/php5/ -type f -cmin +$(/usr/lib/php5/maxlifetime) -print0 | xargs -r -0 rm


Was der Grund für diese Deaktivierung bei Ubuntu oder Debian war konnte ich auf die Schnelle nicht herausfinden, werde es aber in einem Update nachliefern.

Wenn in Linux-Distributionen solche Änderungen vorgenommen werden, sollte man aber passende Toolsets liefern, um alle Variationen abzufangen. So ist das nur eine halbe Sache, wenn ich nichts übersehen habe. Der Bug wurde auch schon im Ubuntu-Bugtracker aufgenommen, aber noch keinem zugeordnet.

Weiterführende Links:

• PHP Dokumenation: session.gc-probability
• Bug bei Ubuntu

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.