Let’s encrypt: Fallstricke bei Domainwechsel

Vor einiger Zeit habe ich die Domain meines Blogs gewechselt – von www.kadder.de auf www.techblogger.net. Dabei gab es einen Fallstrick durch die Verwendung von Let’s encrypt.

Der Ansatz: beim Wechsel der Domain soll natürlich von der alten Domain auf die neue weitergeleitet werden. Das Problem: läuft das Zertifikat der alten Domain ab, führen SSL-Aufrufe zu einem Zertifikatsfehler. Dadurch gehen dann auch Rankings und Besucher verloren, die bisher die alte Seite aufgerufen haben.

Nach einigen Experimenten mit den Nginx-Weiterleitungs-Regeln (um zu verhindern, dass das Verzeichnis .well-known, welches für die webroot-Zertifizierung von Let’s encrypt benötigt wird auf die neue Domain umgeleitet wird) ist die Lösung doch naheliegend.

Um die automatische Aktualisierung des Zertifikats weiterhin nutzen zu können (eine sehr gute Anleitung dafür gibt es bei Digitalocean) ist ein Ansatz die Erweiterung des bestehenden Zertifikats für die neue Domain. Dieses muss zusätzlich auch die bisherige Domain beinhalten.

Ist das erledigt, wird für die alte Domain das gleiche Zertifikat konfiguriert wie für die Neue, mit dem Ergebnis dass die Weiterleitungen auch wieder für SSL-Verbindungen funktionieren.

Nginx: ngx_pageespeed aktuell halten

Wer – wie ich auf tech-blogger.net und routerzwang.de – das Nginx-Pagespeed Modul verwendet, sollte dieses auch aktuell halten. Damit kann man sich etliches an Fehlersuche sparen.

Wenn man schon Nginx selbst kompiliert, und das Module „ngx_pagespeed“ verwendet, muss man nicht nur Nginx aktuell halten, was in den letzten Versionen HTTP/2-Support gebracht hat, sondern auch die entsprechende Module. Nachdem ich dies eine zeitlang vernachlässigt habe, konnte ich mich nicht mehr in das WordPress-Backend einloggen. Die dann nötige Fehlersuche sollte anderen erspart bleiben, deswegen hier die wesentlichen Schritte:

cd
NPS_VERSION=<span style="color: #ff0000;">1.9.32.10</span>
wget https://github.com/pagespeed/ngx_pagespeed/archive/release-${NPS_VERSION}-beta.zip
unzip release-${NPS_VERSION}-beta.zip
cd ngx_pagespeed-release-${NPS_VERSION}-beta/
wget https://dl.google.com/dl/page-speed/psol/${NPS_VERSION}.tar.gz
tar -xzvf ${NPS_VERSION}.tar.gz

Die jeweils aktuelle Version bekommt man direkt bei Google, am 29.11.2015 war dies Version 1.9.32.10-beta. Nachdem man die oberen Schritte durchgeführt hat, kann man Nginx „regulär“ installieren, wobei man bei der Konfiguration darauf achten muss, auch die neue Version des ngx_pagespeed-Moduls verwendet wird.

Wer also unerklärliche Probleme mit seiner Webseite hat und Nginx 1.9.x mit ngx_pagespeed verwendet, sollte – wie eigentlich bei jeder Software – darauf achten, dass die jeweils aktuelle Version verwendet wird. Durch die einfachen Installationsschritte lässt sich dies einfach erreichen.

Nginx: PHP-Alternative HHVM

Wer in Sachen Ausführungsgeschwindigkeit von PHP-Scripten weitere Optimierungen vornehmen will, stolpert früher oder später über HHVM – ein Just-in-Time-Compiler für PHP.

nginx_logoHHVM kann einfach über die Debian-Paketverwaltung installiert werden. Ist das erledigt, kann es im Prinzip wie php5-fpm verwendet werden. Die ganze restliche Konfiguration innerhalb von Nginx habe ich gelassen – dadurch lassen sich gute Vergleiche in Bezug auf die Performance anstellen:
Weiterlesen…

Pagespeed: WordPress in unter 1s laden (Nginx + HTTP/2)

Wer WordPress richtig schnell haben will, kommt ab einem gewissen Punkt mit gängigen Caching-Plugins nicht weiter. Nginx mit HTTP2 hilft weiter.

Seit der Version 1.9.5 unterstützt auch die Open-Source-Version von Nginx das HTTP/2-Protokoll direkt – eine mühsame Konfiguration bzw. das Verwenden von Patches ist damit nicht mehr nötig.

English Version below

Die HTTP/2-Implementierung läuft – zumindest bezogen auf einen Blog wie diesen – stabil und ohne weitere Auffälligkeiten. Der größte Vorteil: herausragende Seitenladezeiten. Um PHP nicht zu sehr zu fordern, verwende ich Microcaching. Dadurch sind die meisten Seiten bereits fertig erstellt und müssen nur noch an den Client ausgeliefert werden.
Weiterlesen…

Nginx: HTTP/2 über Alpha-Patch verfügbar

HTTP/2 wird von immer mehr Browsern unterstützt, nur bei den Webservern klemmt es teilweise noch. Für Nginx ist nun ein erster Patch erschienen, der das neue Protokoll einbindet.

nginx_logoDafür ist es natürlich zuerst notwendig, dass Nginx selbst kompiliert wird. Ich verwende den aktuellen Mainline-Zweig (derzeit 1.9.4) als Basis, dazu muss noch OpenSSL 1.0.2 installiert sein. Im Nginx-Blog ist ein Beitrag mit dem passenden Patch erschienen.

Der Patch selbst ist recht einfach durchgeführt. Zuerst muss die Patch-Datei heruntergeladen werden:

wget http://nginx.org/patches/http2/patch.http2.txt

Ist das geschafft, sollte man zuerst einen Testlauf durchführen. Ansonsten kann es auch in einer Testumgebung zu unnützem Zeitaufwand kommen (folgendes im Nginx-Verzeichnis ausführen, ggf. den Pfad zur Patch-Datei anpassen):

patch -p1 --dry-run < patch.http2.txt

Weiterlesen…

Pagespeed: combine_css mit WordPress

Wer WordPress mit mod_pagespeed bzw. ngx_pagespeed verwendet und den Filter combine_css verwendet, wird feststellen, das nichts passiert. Was ist zu tun?

Der Grund für die Probleme: Das Pagespeed-Modul berücksichtigt keine CSS-Einbindungen, die unterschiedliche IDs haben. WordPress setzt den Namen des CSS als ID bei der Einbindung, am Ende sieht es dann so aus:

link rel='stylesheet' id='wp-pagenavi-css' href='/wp-content/plugins/wp-pagenavi/pagenavi-css.css?ver=2.70' type='text/css' media='all'/

Der Lösungsansatz: die ID sowie den dazugehörigen Wert entfernen. Dafür kann man eine entsprechende Funktion in der functions.php des Themes einbinden:

function remove_style_id($link) {
        return preg_replace("/id='.*-css'/", "", $link);
}
add_filter('style_loader_tag', 'remove_style_id');

Der Hintergrund: der Filter style_loader_tag beinhaltet die Einbindung, die Funktion remove_style_id macht nichts weiter als in der fertigen Ausgabe der CSS-Einbindung in WordPress die ID-Werte zu entfernen. Das „Problem“ besteht schon länger, auf Codecentric.de wurde dieser Lösungsansatz bereits 2011 beschrieben.

Insgesamt braucht man am Ende mit den funktionierenden combine_css das WordPress W3TC-Plugin nicht mehr: Caching wird via Microcaching direkt von Nginx gelöst, alle anderen Seitenoptimierungen erledigt das Pagespeed-Modul im Webserver. Dieser Blog läuft mit einer entsprechenden Konfiguration und erreicht damit sehr gute Speed-Index-Werte.

Managed vServer – die Vor- und Nachteile im Überblick

Wer seinen eigenen Server nicht selbst warten und auf dem neusten Stand halten möchte, kann zu einem Managed vServer greifen. Immer mehr Privatpersonen oder auch Unternehmen greifen zu solch einer Lösung.

Dabei handelt es sich um einen Service, bei welchem eine externe Firma die Kapazitäten für einen virtuellen Server stellt und sich als Käufer lediglich um die Nutzung gekümmert werden muss. Worauf bei einem Managed vServer geachtet werden sollte und was ihn im Detail ausmacht, verrät der folgende Artikel.
Weiterlesen…

Nginx selbst kompilieren

Wer Debian verwendet und auf Nginx setzt, wird früher oder später mit den integrierten Modulen nicht mehr auskommen. Die Lösung: Nginx selbst kompilieren.

Zuletzt aktualisiert am 01.06.2016

Was zuerst kompliziert klingt, ist in der Praxis recht einfach und für den Alltag tauglich – dieser Blog hier läuft mit einer selbst kompilierten Version Nginx 1.11.1. Obwohl unkompliziert, sind doch einige Voraussetzungen nötig, um Nginx unter Debian 7.6 bzw. Debian 8 (Jessie) selbst zu kompilieren:

# apt-get install build-essential
# apt-get install libpcre3 libpcre3-dev libpcrecpp0 libssl-dev zlib1g-dev

Weiterlesen…

kadder.de via IPv6 erreichbar

Eine Meldung in eigener Sache: www.tech-blogger.net ist nicht nur via HTTPS/SPDY erreichbar, sondern hat ab sofort auch eine IPv6-Adresse.

Damit wird zwar keine IPv4-Adresse gespart (die Zahl der zur Verfügung stehenden IPv4-Adressen ist begrenzt, wogegen IPv6 einen nahezu unendlichen Adressraum bietet), dennoch ist es ein Schritt in Richtung des „Internet von morgen“ – wie Google die IPv6-Umstellung nennt.
Weiterlesen…

Pagespeed: Microcaching mit Nginx

Nginx ist für sich schon ein sehr schneller Webserver – er bietet jedoch noch einige interessante Funktionen für Caching, womit Zugriffe auf PHP minimiert werden und Seiten deutlich schneller ausgeliefert werden. Eine kurze Anleitung.

Für diesen Blog verwende ich als Basis die aktuelle Nginx-Mainline-Version 1.7.0 mit ngx_pagespeed-Module. Dafür musste ich nginx selbst kompilieren, was aber kein grundlegendes Problem darstellt und mit den entsprechenden Anleitungen auch auf einem aktuellen Debian-System schnell erledigt ist. Weiterlesen…