Und der Steg nach dem Hochwasser:

Passend dazu Mittelbayerische Zeitung: Grieser Steg in Gefahr

WordPress

Als erste Maßname wollte ich auf das Plugin W3 Total Cache wechseln. Das hatte noch mehr Einstellungsmöglichkeiten. Ich hatte noch ein Problem mit dem Preview-Modus, der sich nicht abschalten lies, doch dazu mehr, wenn ich das klären konnte,

Bei dem Plugin findet man schnell die Einstellungen zum CDN, bei dem Bilder auf einen anderen Server ausgelagert werden können. Das Ganze lässt sich auch mit Hosteurope betreiben, aber nur mit einem Patch. Details finden sich im Artikel WordPress & CDN: W3 Total Cache & Host Europe Cloud Storage.

So kommt man dann schnell bei den Amazon Webservices an, die mit CloudFront ein CDN im Programm haben (wobei ich mir auch viele andere Dienste angeschaut habe). Passend dazu gibts auch einige Artikel: Using Amazon Cloudfront CDN with W3 Total Cache WordPress Plugin und Set up W3 Total Cache with Amazon CloudFront CDN. Abschließend kann man sich noch diese Tipps durchlesen: WordPress W3 Total Cache – Best W3 Total Cache Setup.

LXC

Wo testet man solche Sachen eigentlich am Besten? In einer virtuellen Maschine. Ich habe hierfür LXC Linux Container neu kennen gelernt. Das Setup unter Debian 6 brachte ein Kernelproblem mit sich, durch die keine Speicherlimits einstellbar waren. Unter Debian 7 ist das LXC Paket praktisch unbenutzbar, weil die Templates kaputt sind. Also habe ich zu, ersten Mal Ubuntu auf einem Server eingesetzt, um LXC vernünftig testen zu können. Alle wichtigen Infos finden sich im Ubuntu Server Guide: LXC. Interessant ist auch noch Limiting LXC memory usage, wobei ich bisher die Swap Usage nicht einstellen konnte (doch ein Kernel-Problem?).

nginx

Bei der Gelegenheit habe ich mich dann auch mal mit einer Alternative zu Apache befasst, nämlich nginx. Die Konfiguration ist eigentlich ganz einfach, hier die wichtigsten Links in Kürze:

• Server Block (ähnlich VirtualHost bei Apache)
• Directory Listings anzeigen
• HTTP-Authentifizierung
• HTTP Proxy
• MP4 Streaming

Und warum war der Apache nun so langsam?

Ich hatte in letzter Zeit viele Bilder geblogged, die auf der Startseite zu sehen waren. Ein Webbrowser fragt wohl mehrere Bilder gleichzeitig beim Webserver an. Der Apache war aber so eingestellt, dass er gar nicht so viele Request zugelassen hat. Das hatte ich mal so eingestellt, weil der Apache einen hohen Speicherbedarf durch das PHP vom WordPress hatte. Ich habe als erstes meine Plugins ausgemistet und später dann noch Bilder ausgelagert und damit die Ladezeiten wieder gut in den Griff bekommen.

Steinerne Brücke Blick Richtung Osten

Steinere Brücke, Blick auf die Jahninsel

Bei der Wurstküche

HW100 Schild an der Eisernen Brücke

Die Schleuse am Europakanal überbrückte keine Höhe mehr

Steinerne Brücke Blick Richtung Osten

Steinerne Brücke Blick Richtung Westen

An der Eisernen Brücke

Schlüssel erzeugen

Hierzu befinde ich mich für das Beispiel in /etc/bind/master/keys.

dnssec-keygen -f KSK example.com
dnssec-keygen example.com

Falls dieser Vorgang sehr lange dauert, weil man auf einer virtuellen Maschine unterwegs ist, kann man das ganze unter Ausnutzung von /dev/urandom (unter den üblichen kryptographischen Vorbehalten) beschleunigen:

dnssec-keygen -r /dev/urandom -f KSK example.com
dnssec-keygen -r /dev/urandom example.com

Die Zone in Bind für DNSSEC konfigurieren

Jetzt fehlt nur noch die Konfiguration für die Zone:

zone "example.com" {
  auto-dnssec maintain;
  type master;
  update-policy local;
  file "/etc/bind/master/example.com";
  key-directory "/etc/bind/master/keys";
};

Bind reload und fertig.

Mit den Zonen-Updates bin ich hier aber noch nicht ganz warm geworden. Dazu und hoffentlich auch zu den Key-Rollovern bald mehr. Bin dahin empfehle ich zur weiteren Lektüre: ISC: DNSSEC and Bind.

Artikel Updates

• In der ersten Version den Artikels habe ich die KSK-Generierung nicht mit hin geschrieben.
• Das ganze kann man auch nochmal hier nachlesen: Tony Finch – DNSSEC with BIND 9.8.0

• IPV6/xen-route
• IPv6 and Xen on a Hetzner hosted system

Die Anleitungen sind aber für IPv6-only geschrieben.

Ich habe hier nochmal einen /etc/network/interfaces Eintrag hinterlegt, der einen Dual-Stack Betrieb (IPv4/IPv6) erlaubt:

auto eth0
iface eth0 inet static
 address 188.40.xxx.xxx
 gateway 188.40.xxx.xxx
 netmask 255.255.255.255
 pointopoint 188.40.xxx.xxx
 # Hier die IPv6-Adressen hinzufügen lassen
 up /sbin/ip -6 addr add 2a01:4f8:xxx:77::1/64 dev eth0
 # Route für das Gateway via eth0 hinzufügen
 up /sbin/ip -6 route add 2a01:4f8:xxx::2 dev eth0
 # Default Gateway setzen
 up /sbin/ip -6 route add default via 2a01:4f8:xxx
 post-up  ethtool -K eth0 tx off

Zu beachten ist noch, dass man bei der Verwendung von mehreren IPv6 Adressen in der domU die Haupt-IPv6-Adresse als letztes hinzufügt werden muss. Die zuletzt hinzugefügte Adresse wird per Default für ausgehende Verbindungen verwendet.

• DNSSEC-Signaturen mit Nagios überwachen
• check_dnssec compilieren
• Nagios check_dnssec Plugin Wiki

Nun geht es auf dem Nagios Überwachungsserver weiter.
cd /etc/nagios3/conf.d
Als Vorlage nehme ich immer die localhost Konfiguration als Grundlage her, die ich dann entsprechend anpasse:
cp localhost_nagios2.cfg newserver_nagios2.cfg
Am Ende lasse ich Nagios die Konfiguration neu laden:
/etc/init.d/nagios3 reload

Für die Basis-Installation habe ich übrigens einfach die Debian Pakete installiert, das hat problemlos funktioniert und gleich das Nagios Apache-Verzeichnis mit abgesichert.

Hilfreiche Artikel:

• Nagios: Monitoring Publicly Available Services. Viele Tipps wie man ganz einfach weitere Dienste überwachen kann.
• Installation von Nagios (2.6) + NRPE auf Debian Etch. Von hier habe ich das NRPE Setup.

• Internet Society – World IPv6 Day
• heise online – World IPv6 Day: Tests für den Test und deutschsprachige Teilnehmer
• DENIC beim World IPv6 Day aktiv dabei
• World IPv6 Day | heise Netze