Ernüchternd ist am Ende jedoch die Erkenntnis, dass die gleiche Leistung mit EINER GeForce 295 GTX erreicht werden kann. 4 dieser Karten sollen wohl 90.000 PMKs/s erreichen. Da kann man sich natürlich berechtigterweise fragen, ob WPA sicher vor Bruteforce-Attacken ist. Daher möchte ich die Zeit einmal in der Theorie durchrechnen.

Gegeben sei ein WLAN-Router mit einem 16-stelligen Code nur aus Zahlen. Das würde bedeuten 10 Möglichkeiten (0-9) hoch 16 Stellen also in einer Zahl 10.000.000.000.000.000 verschiedene Möglichkeiten für den werksgesetzten WLAN-Schlüssel. Wenn ich mit dem kleinen zusammengeschusterten Cluster  hier 20000 PMKs/s erreiche sind das 500000000000 Sekunden oder 833333333 Minuten oder 138888888 Stunden oder 5787037 Tage..das wären also ca 16000 Jahre in etwa..wenn man die Entwicklung neuer Internetstandarts bedenkt, wofür man neue Router benötigt ist das also ein ziemlich sinnloses Unterfangen. Hat man 10 Systeme mit jeweils 4xGeForce 295 GTX kann man es auch schon in knapp einem Jahr schaffen, aber das setzt voraus man weiß, dass der Schlüssel tatsächlich nur aus Zahlen besteht und 16-stellig ist. Wählt man für sein WPA-verschlüsseltes WLAN also ein mindestens 10-stelliges Passwort aus Zahlen, Klein- und Großbuchstaben, so ist es mit “normalen”  Mitteln nicht knackbar.

Benchmark erfolgte mit diesen Parametern

ab -n 1000 -c 10 http://SheevaPlug/index.php

Benchmark #1 (ohne Cache)

Server Software:        nginx/0.8.31
Server Hostname:        SheevaPlug
Server Port:            80
 
Document Path:          /index.php
Document Length:        7668 bytes
 
Concurrency Level:      10
Time taken for tests:   390.297 seconds
Complete requests:      1000
Failed requests:        0
Write errors:           0
Total transferred:      8008000 bytes
HTML transferred:       7668000 bytes
Requests per second:    2.56 [#/sec] (mean)
Time per request:       3902.969 [ms] (mean)
Time per request:       390.297 [ms] (mean, across all concurrent requests)
Transfer rate:          20.04 [Kbytes/sec] received

Benchmark #2 (mit Cache)

Server Software:        nginx/0.8.31
Server Hostname:        SheevaPlug
Server Port:            80
 
Document Path:          /index.php
Document Length:        7668 bytes
 
Concurrency Level:      10
Time taken for tests:   90.844 seconds
Complete requests:      1000
Failed requests:        0
Write errors:           0
Total transferred:      8238254 bytes
HTML transferred:       7668000 bytes
Requests per second:    11.01 [#/sec] (mean)
Time per request:       908.438 [ms] (mean)
Time per request:       90.844 [ms] (mean, across all concurrent requests)
Transfer rate:          88.56 [Kbytes/sec] received

Natürlich ist die Betrachtung aller Werte wichtig für das Ergebnis, doch ich nehme für einen ungefähren Performancevergleich die “Time taken for tests” heran, die ohne Cache bei 390 Sekunden und mit Cache bei 91 Sekunden lag. Daraus folgt, dass durch den Einsatz eines Cache-Systems wie hier asy_jpcache etwa Faktor 390/91=4,3 mehr Seiten ausgeliefert werden können.

//Nachtrag: Ich habe (ohne mir noch viel mehr zu Versprechen) zu der oben genannten Konfiguration noch XCache hinzugefügt und es hat mich fast aus den Socken gerissen. Ich hätte ja mit einer winzigen Verbesserung gerechnet, aber seht selbst:

Benchmark #3 (mit Textpattern Cache und XCache)

Server Software:        nginx/0.8.31
Server Hostname:        SheevaPlug
Server Port:            80
 
Document Path:          /index.php
Document Length:        7667 bytes
 
Concurrency Level:      10
Time taken for tests:   26.063 seconds
Complete requests:      1000
Failed requests:        0
Write errors:           0
Total transferred:      8238247 bytes
HTML transferred:       7667000 bytes
Requests per second:    38.37 [#/sec] (mean)
Time per request:       260.625 [ms] (mean)
Time per request:       26.063 [ms] (mean, across all concurrent requests)
Transfer rate:          308.69 [Kbytes/sec] received

Noch einmal konnten die 1000 Abfragen um fast Faktor 4 schneller ausgegeben werden, was am Ende bedeutet, dass ein optimiertes System mit einem Cache für das CMS kombiniert mit einem opcode Cache wie XCache in meinem Beispiel Faktor 390/26=15 schneller arbeiten kann. Mit weiteren Optimierungen ist da sicherlich noch etwas mehr drin, allerdings reicht dieser Wert für mich erstmal locker aus

autoindex on;

Das Ganze sieht dann also zb so aus

server {
        listen   80;
        server_name  domain.de;
        autoindex on;
        access_log  off;

Um Dhyana einsetzen zu können benötigt man einige Abhängigkeiten, die aber schnell installiert sind.

apt-get install perl mplayer imagemagick ffmpeg libfile-chdir-perl libgetopt-argvfile-perl bzip2

Man benötigt noch ein Tool des Mplayers, was aber nicht im Mplayer-Packet enthalten ist. Man läd sich also mal den aktuellen Mplayer-Snapshot:

wget http://www.mplayerhq.hu/MPlayer/releases/mplayer-checkout-snapshot.tar.bz2

was dann entpackt wird..

tar xf mplayer-checkout-snapshot.tar.bz2

Man geht mal in den Tools-Ordner

cd mplayer-checkout-*/TOOLS

und guckt ob die midentify.sh drin ist. Wenn sie es ist kopieren wir sie in unseren Binary-Ordner, in dem Dhyana beim Ausführen nachguckt.

cp midentify.sh /usr/bin/midentify & chmod +x /usr/bin/midentify

Wir besorgen uns nun, da wir die Vorbereitungen abgeschlossen haben, das Perl-Script Dhyana von hier und machen es ausführbar:
http://tobyinkster.co.uk/blog/2008/01/06/dhyana/

wget http://tobyinkster.co.uk/blog/2008/01/06/dhyana/files/dhyana.pl && chmod +x dhyana.pl

Das war es auch schon. Wir können nun das Script ausführen zb. mit:

./dhyana.pl big_buck_bunny_1080p_surround.avi

Und fertig, unsere Vorschau liegt im gleichen Ordner wie das Ausgangsmaterial und sieht dann so aus:

Dhyana bietet noch die Möglichkeit einige Einstellungen anzupassen. Die Parameter könnt ihr  euch hier angucken. Es ist auch sehr einfach im Script selbst ein bisschen rumzuschrauben.

Usage:
      dhyana.pl [options] file [cols [rows [geometry [title]]]]
      dhyana.pl --multi [options] file [file ...]
 
      Options:
        --help                   brief help message
        --man                    full documentation
        --version                print version number
        --verbose, -v            increase verbosity
        --quiet                  no status output
        --path TOOL=PATH         set path for external tool
 
  Capture options:
        --cols=X, -c X           columns of images to capture (default 4)
        --rows=Y, -r Y           rows of images to capture (default 6)
        --geometry=G, -g G       geometry of thumbnails (default 'auto')
        --title=T, -t T          title for thumbnails (filename default)
        --capture-mode=M, -C M   capture technique (default 'auto')
 
  Style options:
        --background             background colour (e.g. 'green', '#00ff00')
        --font-family            path to TTF file for text
        --font-size              size of text in pixels
        --colour, --color        colour for text
        --heading-font-family    path to TTF file for heading
        --heading-font-size      size of heading in pixels
        --heading-colour         colour for heading

Preis: Kostenlos | Webseite

Ruft man den Downloadlink auf sollte sich jeder erstmal wundern, warum man nur eine einzige PHP-Datei herunterlädt um sich dann direkt danach zu freuen, dass Adminer tatsächlich nur eine Datei schlank ist. Die Datei auf den Webserver geladen ist er auch schon installiert, es ist kein weiterer Schritt notwendig. Man kann sich mit seinen Zugangsdaten am MySQL anmelden und gewohnte Operationen ausführen wie Datenbanken erstellen, ändern löschen, Tabellen einsehen und diese ändern..naja so ziemlich alles, was man im Grunde braucht in einer Datei!

Preis: Kostenlos | Webseite | Demo

 mysql -h localhost -u Username -p Datenbankname < /link/zur/datei.sql

Viel Spaß

Nachdem man aus den Binaries per “apt-get install mkvtoolnix” das MKVTool installiert hat kann man auch MKVExtract verwenden. Auf der Kommandozeile guckt man erst einmal was für Spuren in der MKV enthalten sind mit:

mkvmerge -i container.mkv

Ausgegeben wird dann etwas wie:

Track ID 1: video (V_MPEG4/ISO/AVC)
Track ID 2: audio (A_AC3)
Track ID 3: subtitles (S_TEXT/UTF8)

Man weiß also nun, dass der Container 3 Elemente aufbewahrt. Um nun ein Element aus dem Container zu extrahieren benutzt man nun mkvextract, die 2 steht für die ID, die wir ja vorher abgelesen haben:

mkvextract tracks container.mkv 2:tonspur.ac3

Das kann nun ein wenig dauern und ihr habt die extrahierte Tonspur. Um Untertitel zu extrahieren benutzt man dementsprechend folgenden Befehl:

mkvextract tracks container.mkv 3:untertitel.srt

Viel Spaß beim basteln, inspiriert hat mich Geekology

Ich hoffe mit dem Übernehmen der Artikel und der SEO-Anpassung an das neue System werde ich in den nächsten Wochen abschließen können. Ich freue mich ja selbst schon darauf euch die Verwendete Software, Benchmarks und so weiter vorzustellen.

aptitude install mysql-server mysql-client

Kurz und schmerzlos, Passwort vergeben und fertig. Dann wird Nginx installiert, was auch noch easy ist:

aptitude install nginx

Da er sich nach der Installation nicht allein startet tuen wir das:

/etc/init.d/nginx start

Nun installieren wir erstmal PHP und einige Module wie zum Beispiel unter anderem das MySQL Modul.

aptitude install php5-cgi php5-mysql php5-gd php-pear

In der php.ini

nano /etc/php5/cgi/php.ini

ändern wir nun diese Angabe wir folgt

[...]
cgi.fix_pathinfo = 1
[...]

Da Nginx leider nich ab Werk mit PHP-Unterstützung kommt müssen wir diese noch über CGI einrichten. Andere Anleitungen schlagen hier vor den Webserver Lighttpd zu installieren, weil dort das Spawn-fcgi Packet enthalten ist, was wir brauchen. Das ist aber absolut überflüssig, da wir die Packete auch von hier bekommen können:

http://packages.debian.org/de/sid/web/spawn-fcgi

Entsprechende Plattform auswählen (durch Eingabe von “uname -m” in der Shell kann man sein System herausfinden) und herunterladen

wget http://ftp.cl.debian.org/debian/pool/main/s/spawn-fcgi/spawn-fcgi_1.6.2-3_i386.deb

und installieren.

dpkg -i spawn-fcgi_1.6.2-3_i386.deb

Nun starten wir einen Fast CGI Daemon für die PHP-Unterstützung auf Port 9000

/usr/bin/spawn-fcgi -a 127.0.0.1 -p 9000 -u www-data -g www-data -f /usr/bin/php5-cgi -P /var/run/fastcgi-php.pid

und packen ihn zusammen mit dem Startbefehl für Nginx in den Systemstart von Debian.

/etc/rc.local

Meine sieht dann zum Beispiel so aus:

#!/bin/sh -e
#
# rc.local
#
# This script is executed at the end of each multiuser runlevel.
# Make sure that the script will "exit 0" on success or any other
# value on error.
#
# In order to enable or disable this script just change the execution
# bits.
#
# By default this script does nothing.
/usr/bin/spawn-fcgi -a 127.0.0.1 -p 9000 -u www-data -g www-data -f /usr/bin/ph$
/etc/init.d/nginx start
exit 0

Wobei ich den Webserver auch durch einen Benutzer starten lasse. Wir editieren die Standard-Einstellung von Nginx für die default-Seite wie folgt:

nano /etc/nginx/sites-available/default

Dieser Bereich wird geändert:

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

Man beachte dabei die stelle include fastcgi_params, die wegen einem Bug vorher zusammen geschrieben wurde. Das war auch schon alles..man startet Nginx neu und alles funktioniert

/etc/init.d/nginx restart

Viel Spaß

Ich werde eventuell hin und wieder von dem Umbau berichten. Fest steht, es bringt auf jeden Fall mehr Performance von Apache loszukommen und Wordpress ist langsam und umständlich im Vergleich zu anderen Systemen.