Veröffentlicht am

PHP, PEAR, Node.js und ANT unter Windows installieren

Wider die Natur gibt es Programmierer, die unter Windows arbeiten. Damit auch diese leidgeprüften Kreaturen in den Genuss automatisierter Build-Prozesse bzw. der entsprechenden Tools zur Quality Assurance (für PHP, CSS und JavaScript) kommen, habe ich hier mal die Schritte zusammengefasst, mit denen ich die Ant-Builds unter Windows XP und Windows 7 lauffähig bekommen habe. Unsere Builds basieren auf dem „Template for Jenkins Jobs for PHP Projects“ von Sebastian Bergmann. Damit unser Jenkins CI Server auch CSS und JavaScript prüfen kann, haben wir das Template noch um CSSLint und JSHint erweitert.

Die Anleitung wurde unter Windows XP und Windows 7 in der jeweiligen 32-Bit-Version getestet, bei 64-Bit-Installationen müssen entsprechend andere Pakete ausgewählt werden.

1. Die Grundlage: Git und die Git-Bash

Klar: Ohne Git läuft grad mal gar nichts! Aber auch die Git-Bash ist ein wichtiger Bestandteil, denn basierend auf MinGW und MSYS stellt es – ähnlich wie Cygwin – eine POSIX-Umgebung unter Windows zur Verfügung. Alle hier genannten Kommandozeilen-Befehle werden also in der Git-Bash ausgeführt. Zunächst wird die aktuellste Version von Git heruntergeladen:

2. PHP v5.4 mittels XAMPP

Für den Build-Prozess wird von XAMPP eigentlich nur PHP benötigt, deswegen könnte man evtl. auch direkt PHP for Windows installieren. Da es aber durchaus sinnvoll ist, den gesamten Stack lokal zur Verfügung zu haben – um eben auch lokal entwickeln zu können – habe ich hierfür nur diesen Weg ausprobiert, wobei es neben XAMPP auch noch einige weitere freie Alternativen gibt.

3. JDK: Java Development Kit als Voraussetzung für Ant

Ant ist ein Java-Programm, dass ein paar Abhängigkeiten von JDK hat. Je nach Windows-Version muss/kann man sich Version v7 (Windows 7) oder Version v6 (Windows XP) installieren.

4. WinAnt: Ant für Windows

Erst nachdem das entsprechende JDK heruntergeladen und installiert wurde, kann die Installation von Ant beginnen, denn im Installation-Prozess muss der Pfad zum JDK angegeben werden.

5. Node.js und der Paket-Manager NPM

Mittels NPM, also den Node Packaged Modules, die zum Lieferumfang von Node.js gehören, können später CSSLint und JSHint installiert werden.

6. PEAR unter Windows installieren

Das bei XAMPP mitgelieferte PEAR wollte einfach nicht richtig funktionieren, insbesondere die per PEAR installierten Pakete wie PHPUnit oder PHPCS gaben nur Fehler aus oder konnten gar nicht erst gefunden werden. Deswegen habe ich per go-pear.phar das vorhandene PEAR überschrieben. Wie eingangs erwähnt, wird dazu die Git-Bash geöffnet.

Die Schritte sind Folgende:

  1. in das PHP-Verzeichnis der XAMPP-Installation wechseln (sofern der Installationspfad nicht geändert wurde, ist dies C:\xampp\php)
  2. Installationsskript herunterladen und ausführen
  3. PEAR für das gesamte System installieren
  4. die Pfade prüfen (alle Verzeichnisse sollten innerhalb des PHP-Installationspfads liegen, also bspw. C:\xampp\php
  5. ist ein Pfad nicht korrekt – die pear.ini sollte immer im Windows-Verzeichnis abgelegt werden – die entsprechende Ziffer wählen und den korrigierten Pfad mithilfe des Präfix eingeben, bspw. $prefix\pear.ini
  6. damit die PEAR.bat auch in der Git-Bash ausgeführt werden kann, muss in der .bashrc ein alias angelegt werden
cd /c/xampp/php
curl -O http://pear.php.net/go-pear.phar
php go-pear.phar
# 1. für das gesamte System installieren, also mit Eingabetaste bestätigen
# 2. Pfade prüfen und gegebenenfalls korrigieren
#    ACHTUNG! Bitte insbesondere Punkt 11, den Pfad zur perar.ini prüfen und korrigieren:
#      $prefix\pear.ini
echo "alias pear='cmd //c /C/xampp/php/pear'" >> ~/.bashrc

Danach muss – wie vom Installationsskript empfohlen, die folgende Datei ausgeführt werden, die einige Umgebungsvariablen in der Registry hinterlegt:

C:\xampp\php\PEAR_ENV.reg

Damit die Umgebungsvariablen auch garantiert überall ankommen, empfiehlt sich an dieser Stelle ein für Windows obligatorischer Neustart.

7. PHPQA-Tools per PEAR und CSSLint und JSHint per NPM installieren

Das „Template for Jenkins Jobs for PHP Projects“ greift zur Erstellung der API-Dokumentation auf phpDox zurück – das kam allerdings nicht mit allen Projekten zurecht. Deswegen greifen wir auf die Neuauflage des phpDocumentors zurück – zur Zeit ist die Version v2 allerdings noch im Alpha-Status. Dazu müssen lediglich folgende Zeilen in der Git-Bash ausgeführt werden:

pear config-set auto_discover 1
pear install --alldeps pear.phpqatools.org/phpqatools pear.netpirates.net/phpDox-alpha pear.phpdoc.org/phpDocumentor-alpha

Nachdem das abgeschlossen ist, fehlen nur noch CSSLint und JSHint:

npm -g install csslint jshint

Glückwunsch, es stehen jetzt (hoffentlich!) alle Tools zur PHP-, CSS- und JavaScript-Code-Qualitätssicherung zur Verfügung. Hurra!

Schlussbemerkung

Fassen wir zusammen: Es ist kompliziert! Und es dauert. Lange. Aber es funktioniert. Optimal ist diese Variante allerdings nicht, zumal die Ant-Files für Windows noch mal speziell angepasst werden mussten – mehr dazu vielleicht ein anderes mal. Ich denke, VMs per VirtualBox und Vagrant werden die flüssigere Alternative sein. Es bleibt noch viel zu tun… 😉

Veröffentlicht am

SPDY in Nginx aktivieren

Und gleich noch ein Beitrag zum Thema Nginx: SPDY, eine durch Google initiierte Erweiterung von HTTP bzw. HTTPS, kann bis dato (März 2013) nur durch einen Patch in aktuellen Nginx-Versionen (1.3.x) aktiviert werden.

Da sich Nginx ohne weitere Abhängigkeiten kompilieren lässt, kann man auch auf älteren Linux-Installationen von den Nginx-Features profitieren. So habe ich noch einen etwas betagten Gentoo-Server im Einsatz, auf dem sich nicht mehr zuverlässig mit emerge und dem Portage-Tree arbeiten lässt. Gleiches gilt natürlich auch für eher konservativ eingestellte Enterprise-Distributionen wie SuSE oder RedHat, die entsprechend ihres Auftrags nur sehr veraltete Versionen der Software bereitstellen – wenn überhaupt!

OpenSSL mit NPN installieren

Eine Abhängigkeit ergibt sich aufgrund von SPDY aber doch: OpenSSL muss in der Version ab 1.0.1 vorhanden sein, denn erst in dieser Version wurde das für SPDY erforderliche Next Protocol Negotiation (NPN) implementiert.

Für den aktuellen Verwendungszweck reicht es aus, die Sourcen von OpenSSL herunter zu laden und zu entpacken:

cd /usr/local/src
wget http://www.openssl.org/source/openssl-1.0.1e.tar.gz
tar xzf openssl-1.0.1e.tar.gz

Letztendlich ist es nicht zwingend notwendig, OpenSSL zu kompilieren und zu installieren, schaden kann es aber natürlich nicht. Um Konflikte zu vermeiden, kann ein Installationspfad außerhalb von PATH gewählt werden (standardmäßig ist das Zielverzeichnis /usr/local/ssl):

cd /usr/local/src/openssl-1.0.1e
./config
make
make install

Nginx mit SPDY patchen und installieren

Um SPDY in Nginx nutzen zu können, muss der Source-Code von Nginx heruntergeladen und gepatcht werden. Die README zum SPDY Patch beschreibt das sehr gut. Fürs Kompilieren sind außer dem Pfad zum OpenSSL-Source-Code auch die Optionen --with-http_ssl_module und --with-http_spdy_module anzugeben. Damit sich die Installation in die Linux-Umgebung besser einbettet, habe ich außerdem noch ein paar Pfade angepasst:

cd /usr/local/src
wget http://nginx.org/download/nginx-1.3.13.tar.gz
tar xzf nginx-1.3.13.tar.gz
cd nginx-1.3.13
wget http://nginx.org/patches/spdy/patch.spdy.txt
patch -p1 < patch.spdy.txt
./configure --prefix=/usr/local --with-openssl=/usr/local/src/openssl-1.0.1e --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log --http-log-path=/var/log/nginx/access.log --pid-path=/var/run/nginx.pid --with-http_ssl_module --with-http_spdy_module
make
make install

In der nginx.conf muss bei der listen-Direktive ssl und spdy zum Aktivieren angegeben werden:

server {
    listen 443 ssl spdy default_server;

    ssl_certificate      server.crt;
    ssl_certificate_key  server.key;

    ...
}

Verbreitung von SPDY in Browsern

Leider unterstützen noch nicht besonders viele Browser SPDY, zur Zeit sind dies lediglich Google Chrome/Chromium, Firefox und Opera auf den Desktops, bei den mobilen Varianten Android Browser, Opera Mobile, Chrome for Android und Firefox for Android.

Can I use… – für Webentwickler ohnehin zu empfehlen – stellt dazu eine hervorragende Übersicht zur Verfügung: http://caniuse.com/spdy

Veröffentlicht am

OCSP Stapling mit Nginx

Mein neuer Lieblings-Webserver Nginx beherrscht ab der Version 1.3.7 zur Geschwindigkeitsoptimierung von HTTPS OCSP Stapling. OCSP Stapling grob erklärt:

Der Browser prüft beim Aufruf von durch SSL/TLS gesicherte Seiten, ob die verwendeten Zertifikate noch gültig sind, also beispielsweise nicht zurückgezogen wurden. Dazu greifen Browser auf die von den Zertifikatherausgebern (Certificate Authorities, CA) bereitgestellten Certificate Revocation Lists (CRL) zu. Dementsprechend erfordert die Prüfung zusätzliche HTTP-Requests und zur Verarbeitung der Liste Rechenleistung des Client-Rechners. CLRs werden je nach CA alle paar Stunden aktualisiert.

Das Online Certificate Status Protocol (OCSP) optimiert dieses System durch eine Verringerung des zur Prüfung notwendigen Datenvolumen und nahezu Echtzeit-Ergebnissen. Nichtsdestotrotz müssen zusätzlichen HTTP-Requests durch den Browser verarbeitet werden, was dementsprechend zu einer höheren Latenz führt. Auch Ausfälle der CA-Server bzw. DoS-Attacken auf ebendiese sind nicht auszuschließen – der Browser kann dann das Zertifikat nicht verifizieren.

OCSP Stapling kann diese Probleme ein stückweit abfedern, indem der Server selbst die OCSP-Anfrage beim CA-Server vornimmt, für eine gewisse Zeit (und für alle Clients) im Zwischenspeicher vorhält und eine signierte Antwort an die Browser zurück gibt.

Konfiguration von OCSP Stapling mit Nginx

Um OCSP Stapling in Nginx zu aktivieren, muss im http– oder server-Kontext – abgesehen von der SSL-Konfiguration – folgende Option aktiviert werden:

ssl_stapling on;

Das alleine wollte aber nicht ausreichen, der Start von Nginx brach mit folgender Fehlermeldung ab:

nginx: [warn] "ssl_stapling" ignored, issuer certificate not found

Erst nachdem ein ssl_stapling_file angeboten wurde, startete Nginx wie erwartet.

OCSP Stapling File erstellen

Leider wird in der Nginx-Dokumentation nicht beschrieben, wie diese Datei zu erstellen ist. Ich habe dann nach etwas googlen eine Anleitung gefunden, mit der ich die Datei nach einigem Herumwerkeln erstellen konnte – auf Anhieb hat es damit auch nicht funktioniert, unter Anderem da das Zertifikat des Servers die gesamte Zertifikatkette beinhalten muss. Später habe ich aber noch einen Blogpost „Priming the OCSP cache in Nginx“ gefunden, der mittels eines kurzen Skripts für mich deutlich besser funktioniert. Daraus ein Gist gebastelt sieht das folgendermaßen aus:

#!/bin/sh
ISSUER_CER=$1
SERVER_CER=$2

URL=$(openssl x509 -in $SERVER_CER -text | grep "OCSP - URI:" | cut -d: -f2,3)

openssl ocsp -noverify -no_nonce -respout ocsp.resp -issuer $ISSUER_CER -cert $SERVER_CER -url $URL

Als erster Parameter wird demzufolge das Zertifikat des Ausstellers und als zweiter Parameter das Server-Zertifikat erwartet. Das Stapling-File bekommt den Namen ocsp.resp und kann anschließend für Nginx abgelegt werden. Die Konfiguration für Nginx sieht anschließend beispielsweise folgendermaßen aus:

ssl_stapling on;
ssl_stapling_file /etc/nginx/ocsp.resp;