Entries by Roman Schließmeyer

Heute eine kleine, aber feine Zeile aus dem täglichen Leben. Wer aus Redundanzgründen mehrere Nameserver in der /etc/resolv.conf eingetragen hat, sollte ebenfalls erwägen diese Optionszeile hinzuzufügen:

options timeout:1

Dies führt dazu, dass beim Timeout der DNS-Anfrage auf dem ersten Nameserver bereits nach 1s Wartezeit der nächste Nameserver aus der Liste probiert wird. Für viele Applikationen oder Dienste sind einfach die 10s Timeout (Default Wert) zu lange.

Beim Umzug eines Kundenservers von einem dedizierten Server auf eine Xen Plattform konnte ich einmal mehr interessante Beobachtungen machen.

Anforderung war es, den bestehenden Server samt Betriebssystem und Software in eine Xen DomU zu migrieren.

Die ursprüngliche Maschine also ins Rescue System gebootet und via tar einen Komplettbackup erstellt. Auf dem Wirtsystem des neuen Rechners dann die root Partition (im LVM) gemountet und das dorthin kopierte tar.gz wieder ausgepackt. Anschließend notwendige Anpassungen der fstab Einträge, Netzwerkdaten und dergleichen. Da die neue DomU per pygrub gebooted wird, braucht kein Bootloader in das LVM Device geschrieben werden. Allerdings ist es nötig die menu.lst an die neue Festplatte anzupassen (sda -> xvda).

Der erste Startversuch der DomU ergab schließlich ein schnörkelloses "Error: Boot loader didn't return any data!". Das xend.log war leider wenig hilfreich und lies keine Rückschlüsse auf das Problem zu.

Nach längerer Recherche und einigen erfolglosen Versuchen stellte sich heraus, dass pygrub offenbar keine anderen Dateien im /boot/grub Verzeichnis des Gastsystemes toleriert. Nachdem alles bis auf die Datei menu.lst aus dem Verzeichnis entfernt ist, booted die DomU einwandfrei.

• Niedrige TCO durch bedarfsgenaue Ressourcen-Bereitstellung
• Abrechnung abhängig von der Nutzungsdauer (pay-as-you-grow)
• Höchste Rechenleistung und Speicherkapazität, verfügbar on-demand
• Maximale Flexibilität und Skalierbarkeit
• Webinterface und API ermöglichen Ihnen volle Kontrolle über alle Ressourcen
• Vollautomatische Datensicherung
• Sichere und vollständig redundante Betriebsumgebung im eigenen TÜV-zertifizierten TIER-III Rechenzentrum in St. Ingbert, Deutschland
• Ihre Daten verbleiben im deutschen Rechtsraum

Unsere IPv6 Anbindung wurde in den letzten 2 Monaten auf Herz und Nieren getestet und wird zum 31.05.2011 die Testphase offiziell verlassen. Im Zuge dessen freuen wir uns nun auch mit SKYWAY/Key-Systems auf der Liste der deutschen RIPE-Mitglieder mit vollständiger IPv6 Unterstützung aufgeführt zu sein.

http://ripeness.ripe.net/4star/DE.html

Endlich ist es wieder soweit! Die zuvor als Webhostingdays bekannte Veranstaltung präsentiert sich dieses Jahr zum ersten Mal internationalem Publikum. Aufgrunddessen wurde der Name der Veranstaltung als "Worldhostingdays" internationalisiert und auch eine größere Location ausgewählt. Die Worldhostingdays 2011 finden vom 23-25.03.2011 im Europa-Park in Rust statt. Man darf sich auf hochkarätiges Fachpublikum, spannende Vorträge und eine große Hosting.FAIR freuen!

Das SkyWay DataCenter ist nebst Muttergesellschaft Key-Systems natürlich auch mit eigenem Stand (Hosting.FAIR 53) vertreten. Gerne stehen wir für persönliche Gespräche und Informationen vor Ort zur Verfügung und freuen uns über Ihren Besuch. Einen Vortrag von Key-Systems und SkyWay DataCenter CEO Alexander Siffrin gibt es am Donnerstag.

Für weitere Informationen zur Veranstaltung besuche man die Webseite des WHD.

Selten so schön (und völlig unabsichtlich) vertippt:

server ~ # xm lost|grep 65
Error: Subcommand lost not found!

Man braucht es immer wieder und kann es sich einfach nicht merken:

openssl s_client -connect host.name.tld:443

Nach 2 Jahren Entwicklungszeit präsentiert die Debian Entwicklergemeinde am heutigen Sonntag die stabile Version 6.0 (squeeze) Ihres Betriebssystemes. Squeeze machte in den letzten Monaten bereits einen sehr ausgereiften und guten Eindruck im produktiven Betrieb. Die Veröffentlichung entspricht dem normalen Debian Release Zyklus.

Als eine der wichtigsten strukturellen Neuerungen ist die ausschließliche Einbindung von Paketen, Treibern und Firmware auf Basis der GPL oder vergleichbaren freien Lizenzmodellen zu nennen. Alle nicht-freien Pakete wurden aus dem main-tree ausgelagert - den Benutzern soll bewusst gemacht werden, dass es sich bei diesen Paketen nicht um freie Software handelt.

Die offizielle Release Note gibt es hier.

Nachtrag: Den inoffiziellen Debian Release Kuchen gibt es hier

Am gestrigen Donnerstag hat die IANA jeweils einen der letzten 5 verbleibenden /8 IP Adressblöcke an die regionalen Vergabestellen (RIR) verteilt. Damit nähern wir uns wieder einen weiteren Schritt dem Tag X, an dem alle freien IPv4 Adressen "aufgebraucht" sind. Wie gehabt werden die /8 Blöcke von den RIRs nach Bedarf an die einzelnen Mitglieder (LIR) aufgeteilt, von dort aus werden sie meist Ihrem endgültigen Benutzer zugewiesen (Hoster, Carrier, ISP).

Wie lange die restlichen verfügbaren IPv4 Adressen noch den Bedarf decken ist schwer abzuschätzen, sicher mehr als ein paar Tage oder gar Wochen - vielleicht aber auch nicht mehr mehrere Monate oder gar ein Jahr. Zu viele Faktoren spielen eine Rolle um exakte Prognosen abgeben zu können - einige LIRs haben fleißig gehamstert, andere haben sich noch garkeine Gedanken gemacht. Fraglich ist auch ob die IANA nicht doch noch irgendwo wieder ein paar ausgemusterte oder reservierte Blöcke aus dem Hut zaubert und freigibt.

Die in den letzten Tagen heraufbeschworene IPcalypse mag nicht wirklich der tatsächlichen Situation entsprechen, dennoch sollten die letzten Netzbetreiber langsam einmal anfangen sich mit dem Thema IPv6 zu beschäftigen. Das kein Weg daran vorbeigehen wird (früher oder später) ist mittlerweile abzusehen, trotz weiter vorhandener Protokoll-Bugs.

Durch einen Kunden, der einen eigenen MyDNS Master Nameserver und unsere BINDs als Secondary Nameserver benutzt sind wir diese Woche auf ein Problem beim Zonentransfer zwischen beiden Nameserver-Typen aufmerksam geworden. Wird eine Zone auf dem Master Nameserver aktualisiert, gibt es ein Notify an die Slaves. Diese versuchen einen Zonentransfer - scheitern aber mit der Fehlermeldung:

failed while receiving responses: end of file

Der AXFR via dig funktionierte aber problemlos! Nachdem wir nach und nach alle üblichen Konfigurationsfallen überprüft hatten, kamen wir nach einigen Recherchen dahinter, dass MyDNS scheinbar primär einen IXFR, also einen inkrementellen Zonentransfer versucht. Offenbar unterscheiden sich die Implementierungen des IXFR von MyDNS und BIND aber oder sind inkompatibel.

Der Fehler ließ sich nur durch Deaktivierung der IXFRs von BIND Seite beheben, dazu trägt man in die BIND Konfiguration folgendes ein:

options {
...

request-ixfr no;

...
};

Herzlich Willkommen zum RZblog!

Hier wird es in Zukunft in unregelmäßigen Abständen interessante Artikel zum Thema Rechenzentrum, Server und Netzwerke geben. Die Autoren sind Rechenzentrumsbetreiber, Hardwarehersteller und erfahrene Linuxanwender. Kommentare und Diskussionen sind gerne gesehen, bei redaktionellem Interesse besteht auch die Möglichkeit als Gastschreiber aktiv zu werden.