Wenn man langeweile hat kommt ja bekanntlich auf dumme Gedanken. Ich habe momentan ein bisschen mit dem Tool Pyrit zu tun, welches auch eine Netzwerk-Funktionalität bietet. Man kann also eine ganze Serverfarm nutzen um einen WPA-Schlüssel zu knacken wenn man das möchte. Dazu wird ein Server in den Modus “pyrit serve” gesetzt – er wartet dann auf Jobs, die vom Client vergeben werden. Ich habe also mal testweise einige Server verbunden um zu testen was denn so an Rechenleistung bei einem kleinen “Cluster” aus Pyrit-Servern leistungstechnisch geht. Es sind 6 Server an der Zahl: Genauer 1 Dual-Quad-Core, 4 Quad-Core und 1 Dual Core System, die aber alle auch zum Testzeitpunkt normal im Produktiveinsatz genutzt wurden. Der Client rechts im Bilde ist ebenfalls ein Dual-Quad-Core System.
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.
Ich habe heute rein aus reiner Neugierde ausprobiert, wie effektiv das Cache-System asy_jpcache für Textpattern arbeitet beziehungsweise um welchen Faktor die Anzahl der ausgelieferten Seiten steigen würde. Mir ist klar, dass solche Benchmark-Werte nicht die repräsentativsten sind, daher beschreibe ich in aller Kürze die Testbedingungen damit sich jeder selbst ein Bild machen kann. Der Benchmark wird mit ApacheBench auf einem EEE PC ausgeführt und das Gerät, dessen Leistung getestet wird ist eine SheevaPlug mit einem 1,2Ghz ARM Prozessor und 512MB RAM. Der verwendete Webserver ist (natürlich) Nginx in der Version 0.8.31, der auf einem Debian Lenny läuft. Die beiden Rechner sind über einen 100Mbit-Switch verbunden (was aber keine Rolle spielen sollte, da die SheevaPlug ohnehin nicht so viel ausliefern kann). Die Seite, auf die der Benchmark ausgeführt wurde ist die Startseite von Textpattern nach einer frischen Installation.
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 
Das war eine kurze und kleine Problemstellung die ich hatte. Man muss einfach in der Seitenkonfiguration folgendes ergänzen:
Das Ganze sieht dann also zb so aus
server {
listen 80;
server_name domain.de;
autoindex on;
access_log off;
Wer mir der Bearbeitung mit Videos zu tun hat, der hat unter Umständen Interesse an der Erstellung von Vorschau-Bildern. Da mein Rechenknecht keinen Bildschirm hat mache ich einige Sachen über SSH auf dem Server, unter anderem benötige ich ab und an einen Screenshot. Dhyana ist ein ganz hervorragendes Perl-Script, was genau das tut.
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
Wen hat es nicht auch schonmal gestört, dass die Verwaltung von MySQL Datenbanken bei mehreren auszuführenden Operationen auf der Kommandozeile umständlich ist und mit Phpmyadmin ein zu umfangreiches Packet bereitsteht (ca. 10MB), was gerne auch mal bei der Installation in Zusammenhang mit alternativen Webservern rumzickt. Nach dem letzten Zwischenfall als Phpmyadmin noch unbedingt das Packet php5-mysqli brauchte um zu funktionieren reichte es mir und ich suchte nach einer Alternative, die schlank und schnell einsatzbereit ist. Ich fand schnell zu Adminer..
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
Man muss um Datenbanken wieder einzuspielen nicht Programme wie PHPMyAdmin benutzten, wenn man auf seinen Webspace, vServer bzw Root-Server per SSH zugreifen kann. Liegt eine sql-Datei vor so kann man ganz einfach folgenden Command benutzen:
mysql -h localhost -u Username -p Datenbankname < /link/zur/datei.sql
Viel Spaß
