HowTo Archive - Page 2 of 22

HTTP/2 ist angekommen | Apache 2.4.17

Was ist HTTP/2? Diese Frage haben andere bereits ausführlich geklärt. https://http2.github.io/faq/ :) daher wollen wir dies heute in Kombination mit dem Apache Webserver ausprobieren.

Im Februar 2015 hat Google den Support für SPDY bereits zugunsten von HTTP/2 eingestellt. Und die Kompatibilität von HTTP/2 ist in fast allen aktuellen Webbrowsern gegeben, so das es bereits seit einiger Zeit keinen Grund gibt, nicht auf das neue Protokoll zu setzen. Seit dieser Woche unterstützt auch der Apache Webserver (2.4.17) das Protokoll, “Stefan Eissing” hat das Module “mod_http2” gesponsert, welches wir im folgenden testen werden.

Installation unter Ubuntu 14.04 via Fremdquellen (PPA)

Warnung: “Zusätzliche Fremdquellen können das System gefährden.”
–> https://wiki.ubuntuusers.de/paketquellen_freischalten/ppa

Zu beginn stellen wir sicher, dass SPDY nicht mehr verwendet wird.

a2dismod spdy

Und deinstallieren dies am besten direkt, falls dies über den Paket-Manager installiert wurde.

apt-get purge mod-spdy-beta

service apache2 restart

Um die Quellen (/etc/apt/sources.list.d/) nicht manuell zu ändern, installieren wir kurzerhand das Programm “add-apt-repository” via:

aptitude install software-properties-common

# Web: https://launchpad.net/~ondrej/+archive/ubuntu/apache2
# Issues: https://github.com/oerdnj/deb.sury.org/issues
#
add-apt-repository ppa:ondrej/apache2

Falls es beim Hinzufügen des Keys zu Problem kommt, kann man dies auch manuell durchführen:

apt-key adv –keyserver keyserver.ubuntu.com –recv-keys 4F4EA0AAE5267A6C

Anschließend installieren wir das Update via “aptitude“, sodass wir mehr Kontrolle über den Update-Prozess haben.

apt-get update; aptitude

Nach der Installation können wir das “http2”-Module wie folgt aktivieren.

cd /etc/apache2/mods-available/

vim http2.load

# Depends: setenvif mime socache_shmcb
LoadModule http2_module /usr/lib/apache2/modules/mod_http2.so

vim http2.conf

<IfModule http2_module>
ProtocolsHonorOrder On
Protocols h2 h2c http/1.1
</IfModule>

# vim: syntax=apache ts=4 sw=4 sts=4 sr noet

Und anschließend muss das Module nur noch aktiviert werden:

a2enmod http2

service apache2 restart

Um zu testen, ob HTTP/2 via https genutzt wird, können wir z.B. direkt im Chrome nachschauen. Dafür öffnen wir einfach die Seite chrome://net-internals und nutzen oben links im DropDown-Menü den Punkt “HTTP/2”.

Quellen:

Apache + HTTP/2: http://www.us.apache.org/dist//httpd/CHANGES_2.4.17
Nginx + HTTP/2: http://mailman.nginx.org/pipermail/nginx-devel/2015-September/007328.html
HowTo: https://icing.github.io/mod_h2/howto.html
Repo: https://launchpad.net/~ondrej/+archive/ubuntu/apache2
Präsentation: http://slidedeck.io/Schepp/HTTP-2
Demo: https://http2.akamai.com/demo

Mr. Robot | Staffel 1, Folge 1 in a nutshell

Die Fernsehserie folgt einem jungen Programmierer (Elliot), der von dem mysteriösen Mr. Robot für eine Hackergruppe rekrutiert wird und wer die Serie bisher noch nicht geschaut hat, sollte dies nachholen.

In Folge 1 muss Elliot einen Rootkit ausfindig machen, viel mehr werde ich an dieser Stelle nicht vorwegnehmen. Viele der folgenden Befehle sind nicht ohne weiteres auf jedem Linux System auszuführen oder es gibt diese gar nicht. Jedoch versteht bzw. sieht man was diese bewirken sollen.

1. Status

Um das Problem vom Büro aus zu analysieren, werden zunächst Netzwerk und Dienste geprüft.

status -scanports -s WBUSl12345678WB1 -p[80-7655]

Hier hat Elliot sich anscheinend eine Shell-Funktion geschrieben, welche einen Portscan auf der Server “WBUSl12345678WB1” mit der Port-Range 80 bis 7655 durchführt.

Der folgender Befehl würde wirklich funktionieren.

nmap WBUSl12345678WB1 -p80-7655

Als nächstes wird anscheinend geprüft welche Prozesse momentan auf dem Remote-Server ausgeführt werden.

status -services -s WBUSl12345678WB1

Dies könnte auch eine selbst programmiere Shell-Funktion sein, welche sich auf dem Remote-Server einloggt und die Prozesse z.B. via “ps aux” auflistet.

ssh user@WBUSl12345678WB1 ‘ps aux’

Resultat: Die Services sind nicht mehr erreichbar und anscheinend läuft auf dem Server ein Xorg. ;) Da der Fehler nicht einzugrenzen ist, wird Elliot (mit dem Jet) zum Rechenzentrum geflogen, um den infizierten Server zu lokalisieren und zu isolieren. *freu*

2. Ping

Der Befehl selbst ist in der Sequenz nicht zu sehen aber dies könnte so ähnlich aussehen.

fping -g 194.122.82.0/24

Resultat: Ein Server ist noch aktiv, dies muss der Übeltäter sein …

3. Locate WBKUW300PS345672

Der gehackte Server soll in der nächsten Szene manuell durch den Backup-Server ersetzt werden. Es wird der Befehl “Locate” ausgeführt, um sich zunächst an dem gehacktem Server anzumelden.

Der “locate” Befehl ist eigentlich zum suchen von Dateien gedacht, aber diese wird ja auch klein geschrieben.

4. astsu

Hier wird außerdem der fiktive Befehl “astsu” ausgeführt, um Informationen vom Netzwerk-Informationen vom Server zu erhalten.

Folgende Befehle funktionieren tatsächlich…

DNS:

cat /etc/resolv.conf

IP:

ifconfig

ROUTING:

route

In der nächsten Szene sehen wir sowohl die vorherigen aus auch die nächsten Befehle welche auf der Konsole eingegeben wurden.

astsu -close port: * -persistent

Und wie wir sehen übernimmt der Befehl “astsu” auch noch die Funktionalität von “iptables“. ;)

Locate BKUW300PS345672

Hier kommt nocheinmal der “Locate” Befehl zum Einsatz, um sich auf den Backup-Server einzuloggen.

set waneth0* : * 23.234.45.1 255.255.255.0 [45.85.123.10; 45.85.124.10; 45.85.125.10]

Im Output kann man ein “false” sehen, aber Elliot verwendet “-force” um dieses Problem zu lösen. Natürlich ist auch diese Befehl ausgedacht, aber viele andere Linux Kommandos akzepieren ebenfalls einen “–force” Parameter, daher ist dies gar nicht so abwegig.

set -force -ovr02 waneth04 : 23.234.45.62:441 23.234.45.1 255.255.255.0 [45.85.123.10; 45.85.124.10;

Um die IP-Adresse wirklich zu konfigurieren kann man z.B. “ifconfig & route” oder “ip” verwenden.

ip addr add 45.85.123.10/24 dev eth0

ip addr add 45.85.124.10/24 dev eth0

ip addr add 45.85.125.10/24 dev eth0

ip route add default via 23.234.45.1

Resultat: Der gehacket Server ist offline und der Backup-Server hat dessen Funktion übernommen.

5. ps aux | grep root

ps aux | grep root

Nachdem die Gefahr gebannt ist, schau Elliot sich den gehackten Server noch einmal genauer an und findet einen Prozess (pid: 24) welcher mit höchster Priorität (-20) läuft.

astu trace -pid 244 -cmd

Hier tauch eine abgewandelte Version vom fiktiven Befehl “astsu” auf, warum die pid 244 und nicht die 24 weiter untersucht wird, bleibt ungeklärt.

Um einen Prozess tatsächlich näher zu untersuch, würde ich zunächst folgende Befehle nutzen.

strace -p 24

lsof -p 24

Beispiel für “strace” & “lsof”

6. ps aux | grep root | cpuset

ps aux| grep root | cpuset

“cpuset” würde hier nicht funktionieren und ich bin mir nicht ganz sicher was “cpuset” überhaupt macht?!

astu -ls ./root/fsociety/ -a

Nun wird der Inhalt vom Verzeichnis “/root/fsociety/” angezeigt, folgender Befehl würde funktionieren.

ls -la /root/fsociety/

Elliot schau sich nun die README Datei der Hacker an und möchte den Rootkit zunächst im folgenden löschen.

more readme.txt

astu -rm -norecycle /root/ fsociety/

Um das Verzeichnis wirklich zu löschen, müsste der folgende Befehl ausgeführt werden.

rm -rf /root/fsociety/

Aber er entscheidet sich dagegen und ändert stattdessen die Berechtigungen der Datei, so dass nur noch er selber Zugriff darauf hat.

chmod -R ER280652 600

Auch dieser Befehl wird so nicht funktionieren, da man “chmod” und “chown” unterscheidet. Folgende Befehle würden funktionieren.

chmod -R 600 /root/fsociety/

chown -R ER280652 /root/fsociety/

Resultat: Der ursprüngliche Server ist offline, der Backup-Server ist online und der Rootkit ist noch immer im System.

Fazit: echo “Ich mag diese Serie.” | sed ‘s/Serie/Nerd-Serie/’

jQuery Performance

Demos: http://jsperf.com/jquery-performance-2015

Die folgenden Tipps erklären wie man die Performance von jQuery verbessern kann, einfach indem man das Framework korrekt einsetzt und bei kritischem Code auf JavaScript zurückgreift.

– verwende “gute” Selektoren
– verwende Variablen als Cache
– verwende “chaining” -> .function1().function2()…
– vermeide Dom Interaktionen

jQuery-Selektor Performance

Sehr Schnell: $(“#id”) || $(#id).find(“.class”)
Schnell: $(“tag.class”)
Normal: $(“.class”) || $(“.class”).children()
Langsam: $(“tag”)
Langsamer: $(“tag1 tag2”) || $(“.class tag:type”)
Extrem Langsam: $(“.class > *”) || $(“.class :type”)

Daraus ergibt sich z.B. das eine Kombination aus “.class #id” langsamer ist, als ein einfacher “#id”-Selektor. Deshalb ist es bei jQuery auch schneller einen bestimmten Bereich im Dom via “#id”-Selektor zu laden und anschließend in der entsprechenden Variable nach weitern HTML-Fragmenten zu suchen. -> .find()

Zudem sollte man bei Selektoren bedenken, dass rechts immer der spezifischste Ausdruck stehen sollte. Gegebenenfalls benötigt man jedoch gar keine lange Selektoren, wenn man Zugriff auf das entsprechende HTML hat, um dieses zu ändern.

// Unoptimiert:
$(“tag1.class1 .class2”)

// Optimiert:
$(“.class1 td2.class2”)

Demo (#id vs .class):
http://jsperf.com/cached-jquery-selector-2015-v2/2

Demo (jQuery – find):
http://jsperf.com/cached-jquery-selector-2015-v3

Demo (jQuery – find vs jQuery Plugin):
http://jsperf.com/cached-jquery-selector-vs-jquery-plugin

Demo (jQuery – simple vs jQuery Plugin):
http://jsperf.com/jquery-simple-vs-jquery-plugin

Demo (Zepto.js vs jQuery):
http://jsperf.com/cached-jquery-selector-vs-zepto-selector-v2/5

Demo (Zepto.js vs jQuery vs Sprint.js vs JavaScript):
http://jsperf.com/zepto-vs-jquery-2013/103

Demo (Sprint.js vs jQuery):
http://jsperf.com/cached-jquery-selector-vs-sprintjs-selector

Demo (JavaScript vs jQuery):
http://jsperf.com/cached-jquery-selector-vs-javascript

IMMER Variablen als Cache verwenden

Um auf bestimmte HTML-Fragmente im Dom zuzugreifen ist es aus Performance-Sicht hilfreich, wenn man sich einen Teil vom Dom in einer Variable speichert und anschließend nur noch innerhalb von JavaScript arbeitet. z.B.:

// Sehr langsam (& Sinnfrei):
$('.myElement span').each(function(i) {
  $('.myElement span').eq(i).css('color', 'green');
});

// Langsam:
$('.myElement span').each(function() {
  $(this).css('color', 'green');
});

// Langsam:
$('.myElement span').css('color', 'green');

// Schneller:
$('#myElement').find('span').css('color', 'green');

// Noch schneller: (jQuery + JavaScript)
myElement = $('#myElement').find('span');
for (var i = 0, len = myElement.length; i < len; i++) {
  myElement[i].style.color = 'green';
}

// Sehr schnell: (kein jQuery)
myElement = document.querySelector('.myElement');
myElement = myElement.querySelectorAll('span');
for (var i = 0, len = myElement.length; i < len; i++) {
  myElement[i].style.color = 'green';
}

// Sehr sehr schnell: (kein jQuery)
myElement = document.getElementById('myElement');
myElement = myElement.getElementsByTagName('span');
for (var i = 0, len = myElement.length; i < len; i++) {
  myElement[i].style.color = 'green';
}

Demo (mit / ohne Cache-Variable):
http://jsperf.com/cached-jquery-selector-2015-v2

Zusammenfassung:

jQuery ist im Vergleich mit JavaScript oder anderen Frameworks langsamer, aber wenn man z.B. noch den IE8 unterstützen muss, sollte man auf ein umfassendes Framework wie jQuery nicht verzichten, da ansonsten die entgütige Entwicklungszeit (z.B. Bugfixes für IE) die bessere Performance nicht rechtfertigt. Ein weitere Pluspunkt für jQuery sind die viele bereits fertigen jQuery-Plugins. Außerdem kann man die Performance von jQuery verbessern, wenn man beim programmieren von jQuery-Plugins darauf achtet so wenig Dom-Selektoren “$()” bzw. Dom-Interaktionen wie möglich zu nutzen.

Um dies zu bewerkstelligen kann man z.B. auf das jQuery Boilerplate zurückgreifen, so dass man bereits eine erste Programmier-Struktur vorgegeben hat. Dies hat zusätzlich den Vorteil, dass die eigenen Plugins, die jQuery typische Verkettung von Befehlen unterstützen. Außerdem gewöhnt man sich somit daran in Modulen / Plugins zu denken, welche man zudem durch dessen Konfiguration auch wiederverwenden kann.

Zepto.js war bei meinen Tests keine Alternative zu jQuery, da z.B. ein each() kein zepto-object zurückgibt, so dass man innerhalb der Schleife wieder einen Selektor benötigt. Das Framework nutz die Syntax und Namen wie jQuery, verhält sich jedoch leider etwas anders.

Sprint.js war in den Tests bei weitem schneller als jQuery, jedoch unterstützt dieses Framework nur IE 10+, außerdem ist dieses Framework nicht mal ein Jahr alt, die Dokumentation ist noch nicht vorhanden (bzw. verweist auf die jQuery Dokumentation) und es wurde noch nicht von so vielen Entwicklern getestet wie z.B. jQuery.

Links:

– Erklärung zu jQuery- bzw. CSS-Selektoren: http://suckup.de/howto/jquery/crashkurs-jquery-selektoren/
– Effektive CSS-Selektoren: https://css-tricks.com/efficiently-rendering-css/
– jQuery Performance (Tizen): https://developer.tizen.org/dev-guide/2.3.0/org.tizen.guides/html/web/w3c/perf_opt/jquery_performance_improvement_w.htm
– jQuery Performance (jQuery): http://learn.jquery.com/performance/optimize-selectors/
– jQuery Performance (Blog-Post): http://blog.dareboost.com/en/2014/04/jquery-performance-optimization/

Admin meets Frontend

… oder was „JavaScript“ und „Shell-Script“ gemeinsam haben.

Zu beginn muss ich zugeben, dass ich bei meinen ersten Skripten auch nicht auf den Sichtbarkeitsbereich von Variablen (Scope) geachtet habe. Wenn man sich jedoch etwas mit Softwareentwicklung auseinandersetze stellt man schnell fest, dass globale Variablen direkt aus der Hölle kommen und nichts im Quelltext zu suchen haben.

Variablen sind zumindest in der Shell und in JavaScript zunächst global, selbst innerhalb von Funktionen und werden erst durch den Zusatz „var“ bzw. „local“ zur lokalen Variable. In vielen anderen Programmiersprachen erkennt man den Scope einer Variable direkt im Zusammenhang, ist z.B. eine Variable innerhalb einer Methode deklariert, so ist diese nur innerhalb dieser Methode verfügbar. Wird die Variable jedoch innerhalb der Klasse deklariert, so ist diese für die ganze Klasse und somit für alle Ihre Methoden verfügbar.

Es folgen ein paar Beispiele, wo der Inhalt (Title der Beiträge) des RSS-Feeds von “planet.ubuntuusers.de” ausgegeben werden soll.

JS-Beispiel: mit globalen Variablen

Um dies selber zu testen, öffne die Verlinkte Datei im Browser (leere Webseite) und öffne die Entwicklertools (F12), schalte die Ansicht auf “Konsole” und lade die Seite neu. Im Quelltext sind ausschließlich globale Variablen verwendet, jedoch funktioniert dieses Script “leider” wie gewünscht. Das Problem mit globalen Variablen ist, dass man den Quelltext dadurch ggf. schwerer lesen kann und diesen nicht wiederverwenden kann. Wenn man z.B. verschiedene Funkionen als unterschiedlichen Skripten zusammenfügt oder zusammen nutzen möchte, welche jedoch ebenfalls globale Variablen nutzen, dann können da sehr eigenartige Ergebnisse bei herauskommen.

JS-Beispiel: mit lokalen Variablen

In den DevTools von Chrome kann man jetzt den entsprechenden Variablen-Scope sehen. Jedoch ist der Quellcode noch nicht wirklich wiederverwendbar, da wir das zu lösende Problem (also das laden und parsen einer JSON-Datei) nicht auf eine eigene Abstraktionsschicht gebracht haben.

JS-Beispiel: mit lokalen Variablen und Klassen

In diesem Beispiel wurde nun die Klasse “PlanetUbuntuuserJsonData” erstellt welche wiederum von der Klasse “JsonData” dessen Eigenschaften (Variablen & Methoden) erbt. Leider ist der Quelltext hierbei von zirka 50 auf zirka 80 Zeilen erhört worden und funktioniert dabei z.B. nicht im IE < 10. (siehe Kommentare im Quelltext)

JS-Beispiel: ohne Variablen + jQuery

Dieses Beispiel benötigt zwar die “jQuery”-Bibliothek, welche jedoch bereits entsprechende Funktionalitäten kapselt. Vergleich man diesen Quellcode mit der Vorherigem Version, kann man schnell erkennen, das entschieden weniger Quellcode deutlich besser zu lesen ist. ;-)

Shell-Beispiel: mit globalen Variablen (test_1.sh)

In diesem Beispiel sind wieder sehr viele globale Variablen verwendet und wieder funktioniert das entsprechende Skript “leider” trotzdem. Die Funktion “parse_json()” gibt nicht einmal einen Rückgabewert zurück, dafür teilen sich die beiden Funktionen die Variablen. Und im Grunde könnte man den ganzen Quelltext auch einfach ohne Funktionen untereinander schreiben, dies hätte den selben Effekt.

Shell-Beispiel: mit lokalen Variablen (test_2.sh)

Die entsprechende Ausgabe ist bereits im Vorherigen Bild zu sehen. Bei Shell-Skripten kommt es seltener vor, dass man dessen Funktionalität wirklich wiederverwenden möchte, jedoch ist der Quelltext deutlich besser zu lesen, wenn man entsprechende Rückgabewerte und Übergabeparameter verwendet.

Quellen / Links:
– Shell: Advanced Bash-Scripting Guide
– Shell: Coding-Style-Guide von “Oh My Zsh”
– JS: Sichtbarkeitsbereich (Scope) von Variablen
– JS: Objektattribut

Blackfire PHP-Profiler: Fire up the Performance

Am Wochenende habe ich mal wieder ein neues Tool ausprobiert: “Blackfire” ist ebenso wie “Insight” von SensioLabs entwickelt und kann die Performance einer PHP-Anwendung “on the fly” analysieren und visualisieren.

Die Installation besteht aus folgenden Komponenten:

Probe: dies ist die PHP-Extension welche wir auf dem Server installieren
Agent: Dies ist ein Programm, welches ebenfalls auf dem Server installiert wird und die Performance-Daten zu blackfire.io weiterleitet, wo diese dann visualisiert werden
Client (optional): ein CLI-Tool um PHP-Profiling auf der Kommandozeile auszuführen
Companion: dies ist eine Chrome-Extension, welche auf Knopfdruck das PHP-Profiling ausführt
Website: die blackfire.io Webseite zur Darstellung der Ergebnisse

Die Installationsanleitung ist innerhalb von zirka 5 Minuten abgearbeitet und schon kann man schnell und bequem die Leistung / Performance von Änderungen testen und die entsprechenden Ergebnisse miteinander vergleichen.

blackfire.io: Beispiel-Profile von “http://moelleken.org“

PS: wer noch mehr Information benötigt sollte sich Xdebug lokal installieren bzw. aktivieren und die Profile-Daten anschließend via WinCacheGrind (Windows) oder direkt via KCachegrind (Linux) auswerten und visualisieren.

Server-Probleme im Zeitalter von HTTP/2

Ich hatte heute das Problem, dass einige Webseiten extrem langsam bis gar nicht mehr vom Webserver ausgeliefert wurden. Also prüfe ich als erstes mit “htop” ob die CPU ausgelastet ist, danach via “iotop” die Festplatte, mit “iftop” den Traffic, mit “netstat” die offenen Netzwerkverbindungen und via “free” wie viel Speicher noch zur Verfügung steht. Und die Hardware war nicht mal ansatzweise ausgelastet. Nach einigen weitere Tests ist schnell aufgefallen, dass nur “http”-Anfragen betroffen waren. Selbst eine einfach GET-Anfrage eines Bildes ist zeitweise fehlgeschlagen.

Die größte Änderung am Vortag war, dass eine Webseite mit zirka 1 Millionen Usern komplett auf “https://” umgestellt wurde. Daher habe ich kurzfristig wieder auf “http://” umgestellt, jedoch ohne eine Änderung festzustellen.

linux_kill_9 — Quelle: http://www.reddit.com/r/ProgrammerHumor/comments/27vcjg/signal_kill/

Zeitgleich ist aufgefallen das der MySQL-Prozess nicht korrekt neugestartet ist, somit liefen zwei MySQL-Server (ps aux | grep mysql), wobei nur einer wirklich Anfragen angenommen hat. Der zweite Prozess wollte sich nicht mehr via “service mysql restart” neustarten lassen, hat die Fehlermeldung “Can’t connect to local MySQL server through socket ‘/var/run/mysqld/mysql.sock’” produziert und wurde daher via “kill” getötet und anschließend der MySQL-Server neugestartet.

Dies hat auch das Problem mit den langsamen Webseiten behoben, zumindest kurzweilig. Danach hatten “http”-Anfragen wieder Probleme. Im “error”-Logfile (/var/log/apache2/error.log) vom Apache habe ich dann endlich eine Meldung gefunden, welche mich auf die richtige Fährte gebracht hat: “server reached MaxRequestWorkers setting, consider raising the MaxRequestWorkers settings”

Vor einer Woche hatte ich das “SPDY“-Protokoll auf dem Server aktiviert und getestet, alles hat ohne Probleme funktioniert. Dann habe ich gestern die bereits erwähnte Webseite komplett auf “https” umgeroutet und noch immer kein Problem festgestellt. Am Morgen wurden dann Newsletter versendet und eine ganze Menge Leute sind in kurzer Zeit via “https” auf die Webseite gekommen, da das “SPDY”-Protokoll nur mit “https” arbeite haben diese User nicht die üblichen Anfragen (HTTP 1.0 / 1.1) an den Server gestellt, sondern durch Multiplexverfahren mehrere Anfragen gleichzeitig verarbeitet werden.

http-diagram-spdy — Quelle: http://stackoverflow.com/questions/10480122/difference-between-http-pipeling-and-http-multiplexing-with-spdy

Die erste Intuition, dass es etwas mit der “SSL”-Umstellung zu tun hatte war schon mal nicht verkehrt, jedoch hatte ich die entsprechenden Einstellungen nur in der “.htaccess” auskommentiert, die “https”-Verbindungen jedoch nicht zurück nach “http” umgeleitet …

RewriteCond %{SERVER_PORT} !^443
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

… und den Apache nicht neugestartet, somit waren die aktuellen Anfragen noch aktiv und Nutzer welche auf der Webseite waren haben weiter “https”-Anfragen generiert.

Im nächsten Schritt musste nun festgestellt werden, wie viele Apache Prozesse bzw. gleichzeitige Verbindungen einstellt werden mussten und wie man dies am besten konfiguriert. Die Apache-Dokumentation sagt hierzu folgendes:

“The MaxRequestWorkers directive sets the limit on the number of simultaneous requests that will be served … For non-threaded servers (i.e., prefork), MaxRequestWorkers translates into the maximum number of child processes that will be launched to serve requests. The default value is 256; to increase it, you must also raise ServerLimit.”

Also habe ich via …

netstat -anp | grep -E ":80|:443" | grep ESTABLISHED | wc -l

… bzw. zur groben Orientierung via …

ps aux | grep apache | wc -l

… herausgefunden wie viele http(s) Anfragen bzw. Apache Prozesse aktuell vorhanden sind und habe diese Einstellungen zunächst entsprechend hoch eingestellt (“/etc/apache2/mods-enabled/mpm_prefork.conf”), so dass die Webseite wieder korrekt funktionierte. Anschließend habe ich die zuvor beschriebenen Befehle verwendet, um die endgültigen Einstellungen zu ermitteln. Die folgenden Einstellungen sind an einen Server mit 32G Arbeitsspeicher getestet und sollte nicht einfach übernommen werden.

<IfModule mpm_prefork_module>
ServerLimit 1024
StartServers 1
MinSpareServers 32
MaxSpareServers 250
MaxRequestWorkers 1024
MaxConnectionsPerChild 0
</IfModule>

————————————————–

Lösung: Wenn man das “SPDY”-Modul aktiviert und später auf “SSL” umstellt, sollten man vorher die Apache-Konfiguration anpassen! ;)

————————————————–

Es folgt noch ein kleines Tutorial, wie man “SPDY” für Apache installieren kann. Jeder der bereits auf “nginx” umgestiegen ist, kann dies ggf. bereits ohne weitere Installation ausprobieren: http://ginx.org/en/docs/http/ngx_http_spdy_module.html

Installation: SPDY für Apache 2.2

Download: https://developers.google.com/speed/spdy/mod_spdy/

# z.B.: wget https://dl-ssl.google.com/dl/linux/direct/mod-spdy-beta_current_amd64.deb

dpkg -i mod-spdy-*.deb

apt-get -f install

Installation: spdy für Apache 2.4

apt-get -y install git g++ apache2 libapr1-dev libaprutil1-dev patch binutils make devscripts fakeroot

cd /usr/src/

git clone https://github.com/eousphoros/mod-spdy.git

## wähle deine Apache Version

# z.B.: git checkout apache-2.4.7

# z.B.: git checkout apache-2.4.10

cd mod-spdy/src

./build_modssl_with_npn.sh

chmod +x ./build/gyp_chromium

rm -f out/Release/mod-spdy-beta*.deb

BUILDTYPE=Release make linux_package_deb

dpkg-i out/Release/mod-spdy-beta*.deb

Video:

Links:

– Projekt Webseite: http://www.chromium.org/spdy/

– Quellcode: https://code.google.com/p/mod-spdy/wiki/GettingStarted

– “mod_spdy” für Apache 2.2: https://developers.google.com/speed/spdy/mod_spdy/

– “mod_spdy” für Apache 2.4: https://github.com/eousphoros/mod-spdy

– Online-Test für “SPDY”: https://spdycheck.org/

– Präsentation zum Thema “HTTP/2” von @derschepp: https://schepp.github.io/HTTP-2/

– Browserkompatibilität mit “SPDY”: http://caniuse.com/#search=spdy

I ❤ ~/

Vor einiger Zeit habe ich bereits einen Blog-Post über meine “.dotfiles” geschrieben, jedoch habe ich mich damals mehr auf die Installation beschränkt und habe keine Beispiele gezeigt, so dass man den Vorteil der .dotfiles nur schwer erfassen konnte.

Außerdem benötigt man ggf. nur einige Funktionen oder Dateien um sein System an an seine Bedürfnisse anzupassen. Auf der Webseite GitHub ❤ ~/ gibt es sehr gute .dotfiles Sammlungen, welche man einfach “forken” und anpassen und nutzen kann.

PS: wer sich bisher nicht mit “git” auskennt, sollte sich einmal eines der folgenden interaktiven git-Tutorials anschauen:
– try.github.io/
– pcottle.github.io/learnGitBranching/
– gitreal.codeschool.com/

Beispiele zu meinen .dotfiles:

Navigation:
https://github.com/voku/dotfiles/blob/master/.aliases#L75

Farben für die Kommandozeile:
https://github.com/voku/dotfiles/blob/master/.aliases#L116

Nützliche Shortcuts: z.B. date_*
https://github.com/voku/dotfiles/blob/master/.aliases#L295

Copy&Past via “getclip” und “putclip”: https://github.com/voku/dotfiles/blob/master/.aliases#L368

kill & pkill via z-shell: https://github.com/voku/dotfiles/blob/master/.redpill/lib/4_completion.zsh#L122

grep & ack: https://github.com/voku/dotfiles/blob/master/.aliases#L242

git via z-shell: https://github.com/voku/dotfiles/blob/master/.gitconfig

“ls”-aliases: https://github.com/voku/dotfiles/blob/master/.aliases#L196

vim » Automatisch zur letzten Position springen
https://github.com/voku/dotfiles/blob/master/.vimrc

vim » Schell-Suche via “#”

vim » markieren Leerzeichen am Ende der Zeile

vim » Tabs nutzen
https://github.com/voku/dotfiles/blob/master/.vimrc#L564
vim » NERD Tree via “,” + “-“
https://github.com/voku/dotfiles/blob/master/.vimrc.bundles#L18

vim » Autovervollständigung via Tabulatur-Taste
https://github.com/voku/dotfiles/blob/master/.vimrc#L755

Erklärungen zu meinen .dotfiles:

.bash_profile & .bashrc // .zprofile & .zshrc

Wenn man sich direkt über die Konsole einloggt (ohne GUI) oder remote über ssh, dann wird die Datei: “~/.bash_profile” (bash) bzw. “~/.zprofile” (zsh) ausgeführt, um Ihre Shell vor der ersten Eingabeaufforderung zu konfigurieren.
Wenn man jedoch bereits angemeldet ist und ein neues Terminalfenster z.B. in Gnome oder KDE öffnet, dann wird die “~/.bashrc” bzw. “~/.zshrc”-Datei ausgeführt. Außerdem wird die “.[bash|z]rc” auch ausgeführt, wenn man eine neue Bash-Instanze via “/bin/bash” in einem Terminal ausführt. Um zu verhindern, dass unsere Einstellungen automatisierte Skripte negativ beeinflussen, führen wir die folgenden Anpassungen nur bei interaktiven Konsolen aus.

In meiner “.bashrc”-Datei ist nicht viel zu sehen, da diese Datei auf die “.bash_profile”-Datei zugreift, so dass man bei Änderungen nur eine Datei bearbeiten muss. In “.bash_profile#L19” werden wiederum andere Dateien geladen, so dass wir die selben “Funktionen” und “Aliases” sowohl in der “Bash” als auch in der “Z-Shell” verwenden können.

.config_dotfiles

In dieser Datei kann man Einstellungen für meine .dotfiles vornehmen. Wenn du z.B. deinen Standard-User-Namen in der Variable “CONFIG_DEFAULT_USER” hinterlegst, wird diese nicht mehr in der Shell-Prompt angezeigt.

.path

In dieser Datei kannst du Pfade zu deinen Ausführbaren Dateien einfügen, so dass du diese ohne Angabe des Pfades ausführen kannst.

Diese Datei ist nicht im öffentlichen Repository und ist via “.gitignore” aus git verbannt, da es vertrauliche Informationen enthalten kann. z.B.: export PATH=”$HOME/utils:$PATH”

.load

In dieser Datei laden wir weitere optionale Einstellungen, welche ggf. gar nicht installiert und somit auch nicht geladen werden müssen.

.colors

Hier definieren wir einige Farben, welche dann in den folgenden Dateien verwendet werden können. z.B.: COLOR_BLACK=‘\e[0;30m‘

.exports

Variablen in Shell-Scriptes verhalten sich so ähnlich wie in JavaScript. Variablen sind Standardmäßig “global”, dass heißt selbst Variable innerhalb einer Funktion sind anschließend auch außerhalb der Funktion verfügbar. Daher verwenden wir “local” innerhalb von Funktionen, für Variablen welche nur innerhalb der Funktion zur Verfügung steht sollen. Außerdem können wir Variablen via “export” exportieren, so dass diese nicht nur zur Ausführungszeit, sondern anschließend ebenfalls allen Kindprozessen als Umgebungsvariable zur Verfügung stehen.

.icons

Wie die Farben werden auch die entsprechenden Icons exportiert, so dass wir diese anschließend in Funktionen etc. nutzen können.

.aliases

In dieser Datei werden Abkürzungen für komplexe Befehle oder / und Fallbacks definiert, welche anschließend als Befehl ausgeführt werden.

z.B.:
alias starwars=’telnet towel.blinkenlights.nl’
alias sgrep=’grep -R -n -H -C 5 –exclude-dir={.git,.svn,CVS}’

.bash_complete // completion.zsh

Auch wenn die “Z-Shell” (zsh) bessere Tabcompletion bietet, kann man auch in der “Bash” einige Tabcompletion-Features nutzen.

z.B.:

apt- [Tabulator]
apt-g [Tabulator]
apt-get [Tabulator]
apt-get i [Tabulator]
apt-get install [Tabulator] [Tabulator]
apt-get install apa [Tabulator]

.functions

Hier habe ich einige praktische Funktionen gesammelt, welche ich öfters nutze und nicht als Plugin auslagern möchte.

z.B.:
lman() -> “Open the manual page for the last command you executed”
netstat_free_local_port() -> “get one free tcp-port”
iptablesBlockIP() -> “block a IP via ‘iptables'”

Überlegungen: In der “normalen” Programmierung nutzt man lowerCamelCase für normale Variablen / Funktionen und Methoden, jedoch sind eigentlich alle Funktionen in der Shell lowercase z.B.: whoami, updatedb, killall. Ich mich dafür entschieden mich bei neuen Funktionen und Aliases an einem Original-Befehl zu orientieren, so dass man diese nicht neu lernen muss, sondern diese via [Tabulator] nutzen kann.

.extra

Auch diese Datei ist nicht im öffentlichen Repository und ist via “.gitignore” aus git verbannt, da es vertrauliche Informationen enthalten kann. Hier kann man alle zuvor gesetzten Variablen, Einstellungen, Funktionen überschreiben oder ergänzen.

“gzip” für Webseiten

Um das Verhalten von “gzip / deflate” besser zu verstehen, möchte ich als erstes ganz kurz auf den Algorithmus hinter der Komprimierung eingehen. Dafür muss man zumindest zwei Grundlegende Theorien verstehen. Zum einen die sogenannte Huffman-Kodierung, dabei geht darum Text mit möglichst wenig Bits (0 || 1) zu übersetzen.

Es folgt ein einfaches Beispiel:

String: “im westen nichts neues”

Die Länge des Strings beträgt 22 Zeichen, was bei einem 4-Bit-Code (0000, 0001 …) eine Anzahl von 22 * 4 Bit = 88 Bit ergeben würde.

Berücksichtigt man jedoch die Häufigkeit der wiederkehrenden Zeichen, kann man für bestimmte Zeichen, welche oft im String vorkommen, kürzere Bit-Codes nutzen.

Als erstes Zählen wir die Anzahl der vorkommenden Zeichen. Die Zeichen welche die geringste Häufigkeit aufweisen werden anschließend als erstes miteinander Verknüpft und jeweils addiert.

Wie man bereits erkennt bekommen die Zeichen welche nicht so häufig auftreten längere Strecken und somit gleich auch längere Bit-Codes.

Wenn man alle Zweige verknüpft hat, entsteht daraus dann ein Binär-Baum, welcher von oben nach unten gelesen wird.

Die eindeutigen Bit-Codes sind nun z.B.: 00 für e, 100 für n, 1011 für t und so weiter. Nun benötigen wir nur noch 73 Bit anstatt 88 Bit, um den String binär darzustellen. ;)

Das zweite Prinzip hat auch mit Wiederholung von Zeichen zu tun. Die sogenannte “LZ77″ Kompression, welche wiederkehrende Muster in Strings erkennt und durch Referenzen von vorherigen Strings ersetzt.

Es Folgt ein einfaches Beispiel:

String: “Blah blah blah blah blah!”

 vvvvv     vvvvv     vvv
Blah blah blah blah blah!
      ^^^^^     ^^^^^

Wenn man nun die Wiederholung durch eine Referenz angibt, welche aus der Länge des Wortes (” blah” = 5) und Länge der Wiederholungen. (“lah blah blah blah” = 18). Daraus ergibt sich anschließend der folgende komprimierte Text.

Blah b(5,18)!

… aber nun endlich zum praktischen Teil! Es folgen ein paar Beispiele und Überlegungen im Zusammenhang mit Webseiten / Webservern.

1.) “gzip”, ABER weniger ist manchmal mehr

Bei kleinen Webseiten und schwachen V-Servern kann es vorkommen, dass die serverseitige Komprimierung im Gesamtkontext keinen Geschwindigkeitsvorteil bietet, da die Komprimierung ggf. mehr Overhead (Payload, CPU-Rechenzeit, Verzögerung der Auslieferung) mit sich bringt als es Vorteile (geringere Dateigröße) bietet. Zumal viele Dateien (Bilder, CSS, JS) nach dem ersten Seitenaufruf im Cache sind und nicht wieder vom Server ausgeliefert werden müssen. Gerade für mobile Geräte macht die Komprimierung jedoch fast immer Sinn, daher würde ich die Komprimierung immer aktivieren!

PS: hier noch ein Blog-Post zum Thema Webseiten Beschleunigen

GRÜN = Download
GELB = Wartet
BLAU = Verbindung zum / vom Server

Bei “nginx” gibt es zudem ein Modul (HttpGzipStaticModule) welches direkt vorkomprimierte Dateien ausliefert, anstatt diese bei Anfrage zu komprimieren. Jedoch muss man bisher selber dafür sorgen, dass eine entsprechende Datei mit dem selben Timestamp vorhanden ist. (z.B.: main.css & main.css.gz) Falls jemand hier eine Alternative oder ein einfaches Script zum erstellen der zu komprimierenden Dateien hat, meldet euch bitte bei mir oder einfach in den Kommentaren.

2.) “gzip”, ABER nicht für alles

Zunächst sollte man bereits komprimierte Dateien (z.B. JPEG, PNG, zip etc.) nicht noch zusätzlich via „gzip“ ausliefern, da die Dateigröße im schlimmsten Fall noch steigen kann oder zumindest wird für sehr wenig Dateigröße, sehr viel CPU-Zeit auf der Server (Komprimierung) und auf dem Client (Dekomprimierung) verbraucht.

Ich empfehle an dieser Stelle mal wieder die “.htaccess“-Datei vom HTML5-Boilerplate, welche bereits viele Einstellungen für den Apache-Webserver liefert. Außerdem gibt es dort auch eine optimierte Konfiguration “nginx.conf” für den nginx-Webserver.

3.) “gzip”, ABER nicht immer

Die “gzip”-Komprimierung kann Ihre Stärken bei größeren Dateien viel besser ausspielen, da wir ja bereits im theoretischen Teil gelernt haben, dass die Komprimierung auf Wiederholungen aufbaut und wenn wenig wiederkehrende Zeichen und Muster vorhanden sind lässt es sich schlecht komprimieren.

Beim “nginx”-Webserver kann man die minimale zu bearbeitende Dateigröße angeben, sodass eine 6 Byte große Datei mit dem Inhalt “foobar” bei schwacher „gzip“ nicht auf 40 Byte vergrößert wird.

4.) “gzip”, ABER nicht so hoch

Zudem sollte man nicht mit der höchsten Komprimierungsstufe komprimieren, da man pro Komprimierungsstufe immer weniger Erfolg bei immer mehr CPU-Zeit bekommt. Man sollte weniger stark komprimieren und dadurch Rechenleistung /-zeit einsparen, um die Webseite schneller ausliefern zu können.

test2_1.js.gz (schwache Komprimierung)
test2_2.js.gz (normale Komprimierung)
test2_3.js.gz (starke Komprimierung)

5.) „gzip“ + Minifizierung

Durch Minifizierung von CSS und JS kann man die Dateigröße ebenfalls reduzieren, auch wenn man nicht an die Dateigröße von komprimierten Dateien herankommt, außerdem sinkt der Erfolg der Komprimierung, da wir durch die Minifizierung bereits einige Wiederholungen minimiert haben.

Es folgt ein Beispiel mit „jquery.js / jquery.min.js“:

*Zustand*	Größe der Datei	*gewonnene Größe durch die Komprimierung*
nicht minifiziert + nicht komprimiert Datei	250 kB (¼ MB)	–
nicht minifiziert + schnelle Komprimierung	76,3 kB	173,7 kB
nicht minifiziert + normale Komprimierung	68,3 kB	181,7 kB
nicht minifiziert + hohe Komprimierung	68 kB	182 kB
minifiziert + nicht komprimiert Datei	82,3 kB	–
minifiziert + schnelle Komprimierung	30,8 kB	51,5 kB

6.) “gzip” + Komprimierung verbessern

Im Gegensatz zur Programmierung, wo man Wiederholungen vermeidet, sollte man im Frontend (HTML, CSS) gezielt Wiederholungen nutzen, um die Komprimierung zu optimieren. So zeigt das folgende Beispiel wie man die Dateigröße durch die korrekte Positionierung von Attributen der HTML-Tags verbessern kann.

Zwei Dateien mit dem selben Dateigröße, nur die Reihenfolge der Attribute in der zweiten HTML-Dateien (“test1_2.html”) wurden nicht in der selben Reihenfolge angegeben.

Wie man in dem Bild erkennen kann, haben wir die Dateigröße der HTML-Datei um zirka 10% reduziert indem wir den Komprimierungsalgorithmus bei der Arbeit unterstützen. ;)

Videos:

DO EPIC SHIT!

Slides | Demo (source)

Auf der OpenRheinRuhr (Messe mit Kongress rund um das Thema “Freie Software”) habe ich meinen ersten öffentlichen Vortrag gehalten. Dazu habe ich das Thema “Open Source Workflow für Webentwickler” gewählt und mit dem doch sehr einprägsamen Titel “DO EPIC SHIT!” angekündigt.

Gegen alle Erwartungen bin ich pünklich angekommen, auch wenn die Bahn (GDL) gestreikt hat. Also hatte ich noch etwas Zeit, um noch einen `git commit` vorzubereiten, welcher dann live in dem Vortrag automatisch via Jenkins getestet und deployed werden konnte.

Und auch wenn ich den Vortrag nicht so beenden konnte wie ursprünglich geplant, da ich die Zeit irgendwie falsch eingeteilt hatte, hoffe ich trotzdem einiges nützliches gezeigt zu haben. Beim nächsten mal sollte ich dies wohl vor “echtem” Publikum testen, da die Zeit dann anscheinend anders verläuft. ;) Einige Erklärungen und Beispiele von der Demo-Webseite musste ich daher unterschlagen und reiche diese Infos im folgenden nach:

Backend:

Frontend:

Beispiel: UI-Tests
Beispiel: “bower”
Beispiel: “CSSWring”
Beispiel: “Grunt”-Task
Beispiel: “Gruntfile.js” & “package.json“
Beispiel: “Sasa” & “Sass”
Beispiel: “Modernizr” + “Polyfills”

Extras:

PS: Ich werde heute wieder auf der OpenRheinRuhr sein, da auch das heutige Programm sehr interessante Vorträge und Workshops biete. z.B.: Docker, SaltStack, ImageMagick. Gegebenenfalls sieht man sich dort :) wünsche allen Beteiligten viel Spaß!

ShellShock – Sicherheitsproblem bei der Unix-Shell $(bash)

Alle alten Version der Unix-Shell “bash” enthalten eine kritische Sicherheitslücke (CVE-2014-6271), so dass man Befehle z.B. über CGI-Skripte oder via DHCP ausführen kann. Ggf. benötigt nun dein Handy (z.B. CyanogenMod), dein Router oder deinen Mac / Linux / BSD und so weiter Software-Updates.

Teste dein System:

env x='() { :;}; echo vulnerable' bash -c "echo this is a test"

vulnerable
this is a test

Nachdem man die aktuellen Updates eingespielt hat (z.B. via aptitude) dann sollte die Ausgabe folgendermaßen aussehen.

env x='() { :;}; echo vulnerable' bash -c "echo this is a test"

bash: warning: x: ignoring function definition attempt bash: error importing function definition for `x’ this is a test

Technische Erklärung:

(http://seclists.org/oss-sec/2014/q3/650)
Das Problem ist, dass das man zwischen unterschiedlichen Bash-Instanzen Variablen und Funktionen teilen kann.

export foo='() { echo "bar" ; }'

bash -c 'foo'

Jede neue Bash-Instanz wird nun beim Start die Funktion “foo” registrieren, so dass man diese Ausführen kann. Wenn man nun jedoch eine Funktion exportiert, führt die Bash den nächsten Befehl ebenfalls aus, da der String der “() {” nicht korrekt geparst wird. Damit können wir nun Befehle ausführen, indem wir bestimmte Strings (Funktionsdefinitionen) an z.B. ein CGI-Skript übergeben.

Links:

http://www.heise.de/newsticker/meldung/Bash-Luecke-ShellShock-ist-noch-nicht-ausgestanden-2403607.html

http://www.heise.de/newsticker/meldung/ShellShock-Standard-Unix-Shell-Bash-erlaubt-das-Ausfuehren-von-Schadcode-2403305.html

http://ftp.gnu.org/pub/gnu/bash/bash-4.3-patches/bash43-025

Installation unter Ubuntu 14.04 via Fremdquellen (PPA)

Ähnliche Beiträge:

Ähnliche Beiträge:

jQuery-Selektor Performance

IMMER Variablen als Cache verwenden

Zusammenfassung:

Ähnliche Beiträge:

Ähnliche Beiträge:

Ähnliche Beiträge:

Installation: SPDY für Apache 2.2

Installation: spdy für Apache 2.4

Video:

Links:

Ähnliche Beiträge:

Beispiele zu meinen .dotfiles:

.bash_profile & .bashrc // .zprofile & .zshrc

.path

.bash_complete // completion.zsh

.extra

Ähnliche Beiträge:

1.) “gzip”, ABER weniger ist manchmal mehr

2.) “gzip”, ABER nicht für alles

3.) “gzip”, ABER nicht immer

4.) “gzip”, ABER nicht so hoch

5.) „gzip“ + Minifizierung

6.) “gzip” + Komprimierung verbessern

Videos:

Ähnliche Beiträge:

Slides | Demo (source)

Ähnliche Beiträge:

Teste dein System:

Technische Erklärung:

Links:

Ähnliche Beiträge: