Ich nutzte die Gunst der Stunde un bloggte einen Artikel mit dem Titel “DJ Tomekk fliegt aus Camp – die Gründe…”. Viel zu sagen hatte ich allerdings nicht, da ich natürlich keine Insider-Infos besaß. Ich beschrieb das Ganze einfach als Server-Benchmark, machte noch einen kleinen Scherz und wartete ab. Es dauerte nicht lange und die Besucher kamen in rauen Mengen. Sie riefen den Artikel auf, Einige posteten Kommentare. Innerhalb von ca. 20 Minuten stand der Server so dermaßen unter Last, dass selbst der Zugriff via SSH Ewigkeiten benötigte. Mit letzter Kraft konnte ich den Webserver abschalten, um zumindest die anderen Services wieder nutzen zu können. Am nächsten Morgen war der Spuk dann vorbei.

Grund für den Besucher-Ansturm war oben genannter QDF-Algorithmus: Ähnliche Suchabfragen von vielen Benutzern in kurzer Zeit signalisierten der Google-Suche, dass hier gerade offenbar irgendwas Neues passiert sein muss und lieferte daher möglichst aktuelle Artikel in den SERPs vor allen anderen aus. Einer der aktuellsten Beiträge war tatsächlich von mir – Jackpot!

Am 3. November 2011 hat Google im offiziellen Blog verkündet, durch ein kürzlich erfolgtes Update nun noch frischere Ergebnisse liefern zu können. Dies soll ca. 35% aller gestellten Suchanfragen beeinflussen. In Zukunft kann die Suche also noch effizienter mit aktuellen Ereignissen umgehen: Eine Suche nach aktuellen Themen, z.B. [Olympiade] bringt nun eher Webseiten zur bevorstehenden Olympiade statt der Olympiade von 1900. Wiederkehrende Themen, wie z.B. [Fußballergebnisse] werden genauso optimiert wie auch gelegentliche Updates, wie [subaru impreza reviews].

Wichtig bei diesen Suchanfragen ist natürlich auch, dass jede Anfrage unterschiedliche Anforderungen an die Gewichtung der Aktualität hat. Die Suche nach einem [Rezept für Tomatensuppe] muss nicht das neueste, sondern das “beste” Rezept liefern. Die bessere Unterscheidung dieser Gewichtung ist ebenfalls Teil des Updates.

Allgemeine Infos zu IPv6, die grundsätzliche Konfiguration unter Linux und die Einrichtung eines SixXS-Tunnels werden bereits ausgezeichnet im IPv6-Wiki von Ralf Krüdewagen beschrieben, daher werde ich hier nicht nochmals darauf eingehen.

Stattdessen erzähle ich über ein paar Dinge zu DHCP und DNS, die mir erst heute klar geworden sind und zeige, wie die technische Umsetzung funktioniert. Mag sein, dass ich mich hier und da nicht ganz korrekt ausdrücke… Feedback ist willkommen. :-)

Zusammengefasst sind Stand heute folgende Funktionen möglich:

• IPv6-Tunnelnutzung mit SixXS
• Router Advertisement mit radvd
• DHCP-Server für IPv4 / IPv6
• DNS-Server für IPv4 / IPv6
• dynamische DNS-Updates (DDNS) für IPv4 / IPv6

Im Doppelpack

Ich bin bisher davon ausgegangen, dass man entweder “radvd” oder einen IPv6-fähigen DHCP-Server für die dynamische Zuweisung von IP’s verwendet. Richtig ist aber, dass beide Dienste als Team arbeiten. radvd verkündet im Netz lediglich das IPv6-Prefix, also das zu verwendende Subnetz und Angaben zum Router. Clients weisen sich anhand dieser Informationen selbst eine IP-Adresse zu. Wird nur radvd eingesetzt, spricht man von Stateless Address Autoconfiguration. In diesem Szenario können sich Clients bereits im Netz bewegen und mit anderen IP-Adressen/Hosts kommunizieren.

In einem typischen (Heim-)Netzwerk reicht das jedoch nur sehr selten. Das wohl wichtigste Feature ist das Zuweisen eines DNS-Servers. Hinzu kommen Optionen wie z.B. Domain-Name, Such-Suffixe, PXE oder WPAD-Angaben. Genau hier setzt der DHCP-Server auf, der den radvd sinnvoll ergänzt.

Kurz: IP-Adressen kommen vom radvd, Zusatz-Optionen vom DHCP-Server. Man spricht hier von “Stateful Address Configuration”. (siehe auch IPv6-Autokonfiguration bei Wikipedia).

Die technische Umsetzung:

Die radvd-Konfiguration wird auf ein Minimum reduziert. Wichtig ist die Option “AdvManagedFlag on”. Die Angabe eines prefix-Bereichs entfällt.

“/etc/radvd.conf”:

interface eth0
{
        AdvSendAdvert on;
        AdvManagedFlag on;
        MinRtrAdvInterval 5;
        MaxRtrAdvInterval 10;
}

Ich nutze unter openSUSE 11.4 den ISC DHCP Server (RPM-Paket “dhcp-server”), derzeit in der Version 4.2.1. Dieser Dienst besteht aus zwei Komponenten, “dhcpd” für IPv4 und “dhcpd6″ für IPv6. Ich beschäftige mich in diesem Artikel ausschließlich mit Letzterem. Die DHCP-Konfiguration wird in zwei Dateien vorgenommen:

“/etc/sysconfig/dhcpd” (Auszug):

DHCPD6_INTERFACE="eth0"

“/etc/dhcpd6.conf” (<- auf die “6″ achten!):

authoritative;
ddns-update-style interim;
ddns-updates off;

default-lease-time 2592000;
preferred-lifetime 604800;
option dhcp-renewal-time 3600;
option dhcp-rebinding-time 7200;
option dhcp6.info-refresh-time 21600;

allow leasequery;

log-facility local7;

subnet6 2001:xxxx:yyyy::/64 {

        range6 2001:xxxx:yyyy:: /64;

        option dhcp6.name-servers 2001:xxxx:yyyy::1;
        option dhcp6.domain-search "ipv6.site site";
}

(IP-Adressen wurden anonymisiert)

Wenn nun beide Dienste gestartet wurden und keine Firewall im Weg ist, sollten Clients bereits in der Lage sein, eine IPv6-Adresse inkl. Router- und DNS-Server-Adresse zu beziehen. In Kürze werde ich außerdem beschreiben, wie dynamische DNS-Updates mit IPv6 funktionieren.

Ich bemerkte eher zufällig, dass das Aufrufen beliebiger Artikel und Kategorien-Seiten bloß noch in 404-Fehlern endete…

Kurz und knapp: Der Grund hierfür waren die Permalinks. Unter “Einstellungen -> Permalinks -> Allgemeine Optionen” verwende ich die Option “Benutzerdefinierte Struktur” mit dem Wert “/%postname%/”. Lösen konnte das Problem dann tatsächlich dadurch, dass ich die Permalink-Struktur pro Blog (!) zunächst auf “Standard” umstellte, die Einstellung speicherte und dann wieder die ursprüngliche Einstellung aktivierte.

Möchte gern mal einen WordPress-MultiSite-Betreiber in einer wirklich großen Umgebung sehen. Da gibt’s dann wohl Einiges zu tun.

Die genaue Fehlermeldung war “Error: Device 0 (vif) could not be connected. Hotplug scripts not working.“. In der Datei “/var/log/xen/xen-hotplug.log” war außerdem zu lesen: “/etc/xen/scripts/xen-hotplug-cleanup: line 24: [: !=: unary operator expected".

Anscheinend ist an der entsprechenden Stelle im genannten Skript nun eine Variable leer, die eigentlich gefüllt sein sollte. Das Ergebnis ist nun jedoch ungültig, woraufhin das Skript auf die Nase fällt. Bis Novell ein Update zur Verfügung stellt, um den Fehler zu beheben (ich hoffe, dass Novell die Lösung beisteuert) kann man sich mit einem Workaround helfen, der darin besteht, die Zeilen 24 und 25 im Skript "/etc/xen/scripts/xen-hotplug-cleanup" anzupassen:

aus:

if [ $(xenstore-read "$vm_dev" 2>/dev/null) != "" ]
&& [ "${path_array[1]}” = “vbd” ]; then

wird:

if [ x$(xenstore-read "$vm_dev" 2>/dev/null) != "x" ]
&& [ x"${path_array[1]}" = "xvbd" ]; then

Damit sollte das Problem umgangen werden können. Bisher funktioniert's bei mir ohne Probleme.

UPDATE (20.07.2010):

Meine Xen-Umgebung lief in den letzten Tagen ziemlich wackelig. Das Starten von domU's war möglich, wenn ich allerdings eine der Instanzen stoppen oder neu starten musste, befand sie sich für ca. eine Minute im "paused"-Zustand und brach dann ab. Die Meldung war (wie gehabt) "Error: Device 0 (vif) could not be connected. Hotplug scripts not working.".

Ich habe Foren durchsucht, Manuals gelesen und diverse Mailinglisten umgegraben, doch zunächst schien nichts zu helfen, was auch immer ich versuchte.

Nun habe ich endlich das Problem für mich isoliert und "vorerst" behoben. SLES11SP1 nutzt in der Standardauslieferung für Xen das Kernelpaket "kernel-xen-2.6.32.12-0.7.1". Damit lief alles reibungslos. Dann kam vor einigen Tagen ein Kernel-Patch heraus, Version "kernel-xen-2.6.32.13-0.4.1". Und hiermit fing - wie anfangs bereits vermutet - der ganze Ärger an. Ich habe mittlerweile die Version wieder auf den Originalzustand zurück gedreht und schon funktioniert alles wieder reibungslos. Ich hatte war vor ein paar Tagen schon probiert, den Kernel zurück zu drehen, doch ich hatte auf meinem Server noch ein weiteres Problem, dass mit dem Booten von Software-RAID-Partitionen zusammen hing. Das konnte ich beheben, indem ich "mkinitrd-2.5.10-4.6.1" installierte. Ich glaube aber nicht, dass es sich hierbei um ein grundsätzliches Problem handelt... aber wer weiß. :-)