Das beste Notebook, das ich jemals besessen habe, ist seit knapp zwei Jahren im Vollausbau. Dachte ich. Nun ja, fast. Da dort nur PATA-Festplatten hineinpassen, dachte ich bisher, bei 250 GB sei Schluß - denn es gab bis vor einiger Zeit keine größeren 2,5-Zoll-PATA-Festplatten - jetzt gibt es eine 320-GB-Platte von WD, die auch den meisten "bang for the buck" (lies: den niedrigsten per-Gigabyte-preis) haben. Aber irgendwie widerstrebt es mir, Geld in eine Auslauftechnologie zu investieren, wie es PATA nun einmal ist.
So ist auch der hier im Haus vorhandene Multibay-Rahmen für eine zweite PATA-Festplatte bisher nur bei Migrationen etc zum Einsatz gekommen.
The main showstopper for IPv6 in my private network environment was the non-availability of IPv6 payload support on OpenVPN's multi-client server mode. I am using the OpenVPN multi-client server mode exensively with a number of clients, and adding IPv6 to my OpenVPN network would have meant re-building most of it without multi-client server mode. This would mean having a rather dirty construction with one process per client or even **gasp** bridging. I did not have the heart to actually do this and stayed with IPv4.
Thankfully, these times are over: Gert Döring, Thomas Glanzmann, Bernhard Schmidt and Jan Dirnberger spent the better part of the christmas holidays implementing IPv6 payload support in OpenVPN multi-client server mode. They have published a patch against OpenVPN 2.1 and a number of binary packages implementing this feature that I've been waiting for.
Unfortunately, the IPv6-over-OpenVPN-multi-client-mode patch clashes with the well-known OpenVPN-over-IPv6 patch, so I had to disable it in my locally patched version of Debian's OpenVPN package. Bernhard's binary packages contain both patches.
Enabling IPv6 multi-client server mode is really a breeze. Add server-ipv6 and route-ipv6 statements to your server configuration, and you're done. Client-config-dir works for IPv6 as well, so I can assign static IPv6 addresses to the clients and tell them to point their IPv6 default route into the tunnel from the server by virtue of a ifconfig-ipv6-push and a push route-ipv6 statement inside the client-config-dir file.
That's it. Clients with unpatched client software can still connect (and will only get IPv4, just as before), and clients with patched client software will transparently get IPv6 additionally to the IPv4 tunnel. Now, I only have to pay attention again what services are running on my laptop - it's publicly visible on the intarwebs again.
Guys, your work rocks. I really really appreciate that. Good Job. I owe you more than a beer. Now we only need to convince OpenVPN upstream to accept your patch.
It is well known that apt has an issue when it comes to resolving circular dependencies. Therefore, Debian bug reporters have set out to eradicate circular dependencies from the archive. This does, however, add significant bloat to the actual packages, and I am questioning why this is really necessary.
In the last few days, I found the time to spend some with KVM and libvirt. Unfortunately, there is a subject that I haven't yet found a satisfying solution: Naming of block devices in guest instances.
This is surely a common issue, but solutions are rare. Neither an article on Usenet (in German) nor the German version of this blog article has found solutions for the main question. I should have written this in English in the first place and am thus translating from German to english, hoping that there will be some answers and suggestions.
KVM is quite inflexible when it coms to configure block devices. It is possible to define on the host, which files or whole devices from the host should be visible in the guest. The documentation suggests that devices should be brought into the guest with the virtio model, which needs suppport in the guest kernel. Importing a device as emulated ATA or SCSI device brings a performance penalty.
The devices brought into the guest via virtio appear in the guest's dev as /dev/vd<x> and do also have their corresponding entries in /dev/disk/by-uuid and /dev/disk/by-path. The vd<x> node is simply numbered in consecutive order as hd<x> and sd<x>. /dev/disk/by-uuid is the correct UUID of the file system found on the device, at least if it's a block device partitioned inside the guest and formatted with ext3 (I didn't try anything else yet). The terminology of the /dev/disk/by-path node is not yet understood, and I am somewhat reluctant to assume the PCI paths of emulated hardware as stable.
Wenn eine Applikation über das Netz kommuniziert, funktioniert sie natürlich nur dann, wenn das Netz zwischen den beteiligten Maschinen diese Kommunikation auch durchleitet. Das ist im Internet üblicherweise der Fall; beim Übergang zwischen privaten Netzen und dem Internet in aller Regel nicht: Dort ist eine Firewall im Einsatz, die üblicherweise nach der Deny-all-Strategie alle Kommunikation blockiert, die nicht explizit freigegeben ist.
Auf diese Weise wird man im allgemeinen für eine neue Applikation eine Anpassung an der Firewall vornehmen müssen - es sei denn, die Applikation gibt sich Mühe, wie ein Dienst auszusehen, der üblicherweise freigegeben ist. Das tun zunehmend viele Applikationen und geben sich durch Benutzung von http als Transportprotokoll als Webclient und Webserver aus, was in vielen Firewalls direkt freigegeben ist. Doch dies ist Stoff für einen anderen Artikel.
In diesem Artikel möchte ich davon schreiben, wie die Spezifikation aussehen soll, damit der Firewalladmin auch weiß, was er für eine neue Applikation in seiner Firewall freischalten soll. In vielen Dokumentationen über (freie oder kommerzielle) Software findet man Listen von Ports, die mehr oder weniger vollständig und mehr oder weniger korrekt sind. Leider trifft in den meisten Fällen das "weniger" zu.
Wenn irgendwas unerwartet schief läuft (und das wird es - niemand kann für alle Eventualitäten planen), schreibt Euch auf, was wann wie nicht funktioniert hat, notiert, welche Tests Ihr durchgeführt habt und woran es schließlich lag. Daraus könnt Ihr nur lernen, und im Zweifel hilft Euch diese Dokumentation, um in der Nachlese zu erklären, was da eigentlich passiert ist. Wer schreibt, der bleibt - dieser Spruch ist nie so wahr wie in Streitigkeiten mit dem Kunden. Ich habe gute Erfahrungen damit gemacht, ein Diktiergerät neben mir liegen zu haben, denn ein kurzer Zwischenstand lässt sich schneller sprechen als schreiben, und nebenbei hat es auch noch den Vorteil, dass der Kunde einem nicht über die Schulter guckt und in dem Text, den man eben nur so als Gedächtnisstütze hingeschludert hat, anfängt herumzukorrigieren. Zeit, um das diktierte zu schreiben und in druckreife Form zu gießen, habt Ihr außerhalb der heißen Migrationsphase noch genug. Im Nachhinein geschriebene Braindumps sind oft zu lückenhaft und manchmal auch schlicht inkorrekt.
Achtet darauf, dass die korrekte und aktuelle Zeitplanung nicht nur mit Eurem technischen Ansprechpartner abgeklärt ist, sondern dass auch das Management und der Benutzersupport Bescheid wissen und den Zeitplan abgenickt haben: Das eine macht Euch im Zweifel bei Misstverständnis mitten in der heißen Phase die Hölle heiß, das andere kann Euch den Rücken von störenden Rückfragen freihalten. Etabliert einen Verteiler, über den Ihr bei Verzögerungen zeitnah informiert, damit der angenehme Zustand der Ruhe beim Arbeiten möglichst lang aufrecht erhalten werden kann. Nehmt bei größeren Aktionen einen Praktikanten oder Azubi mit, der für Euch die Kommunikation mit der Außenwelt macht: So habt ihr den Kopf frei für Euren eigentlichen Job.
VPNs sind eine Thematik, die einem besonders bei Firewallprojekten immer wieder schmerzhaft auf die Füße fallen. Im Gegensatz zur klassischen Firewall hat man es bei VPN-Links oft mit Setups zu tun, bei denen man von einer Gegenstelle und deren technischer Kompetenz oder Kooperationsbereitschaft abhängt.
Teil des Projektplans sollte eine Liste der Dienste sein, deren Funktionsfähigkeit während der Migration möglichst schnell wieder herzustellen ist. Dabei sollte man darauf achten, dass man für die notwendigen Tests nicht auf die Mitarbeit anderer angewiesen ist, sprich: Es sollte eine Testprozedur vorab definiert sein, nach deren erfolgreichem Ablaufen der Dienst als "verfügbar" klassifiziert ist. Wenn hierfür Zugangsdaten notwendig sind, muss der Kunde diese zur Verfügung stellen. Ein Testaccount reicht natürlich, aber dann muss es dem Kunden auch reichen, wenn nur mit dem Testaccount getestet wird.
Ganz wichtig: Die Testprozeduren muss man unbedingt vor dem Beginn der eigentlichen Migration einmal selbst ausgeführt haben. Nur so ist sichergestellt, dass man die Prozedur verstanden hat, und dass der Dienst vorher überhaupt funktionstüchtig war. Wenn man diese Prüfung unterlässt, kann es sein, dass man nach der Migration stundenlang herumdebugged und dann zu dem Schluß kommt, dass der Dienst schon seit Tagen kaputt ist, es nur keinen interessiert hat, man mit der Debuggingaktion nur sein eigenes Projekt verzögert hat und man selbst das Ding gar nicht reparieren kann weil man schlicht nicht schuld daran ist dass es nicht funktioniert.
Kommunikation verhindert Mißverständnisse. Das ist in komplexen Systemen wichtig, und zwar insbesondere in einem Migrationsprojekt, wo man den aktuellen Betriebszustand zu Beginn der eigentlichen Migration, der so G*tt will "System funktioniert" heißt, erstmal massiv verschlechtern muss, denn ganz ohne Downtime geht eine Migration in aller Regel nur mit massivstem Materialaufwand.
Deswegen kommt es bei einem Migrationsprojekt darauf an, dass man glasklar mit dem Kunden bespricht, wie die Migration ablaufen wird, wie der Zeitplan ist, und zu welchen Zeitpunkten mit welchen Teilfunktionalitäten des Systems (nicht) gerechnet werden kann. Wenn der Kunde von einem anderen Ablauf der Migration ausgeht als man selbst, gibt das Ärger, und zwar nicht selten mitten in der Migration.
Bei einer Migration ist es immer wichtig zu wissen, womit man es zu tun hat. Dazu gehört insbesondere die Sammlung von Informationen, die man braucht, um das neue System erfolgreich an den Start zu bekommen.
Oft stolpert man bei der Vorbereitung einer Migration auf Altlasten, deren Implementierung im neuen System zwar möglich ist, man das aber aus verschiedenen Gründen nicht möchte. Manche Kunden sind dazu bereit, im Rahmen des laufenden Projekts auch an anderen Stellen Anpassungen vorzunehmen, die ihnen in Zukunft das Leben erleichtern. Man sollte sich nicht scheuen, solche Maßnahmen vorzuschlagen - etwas Blick über den Tellerrand hat noch keinem geschadet.
Oft hat man vor dem Einstieg in die heiße Migrationsphase die Gelegenheit, die neuen Systeme vorzubereiten und zumindest teilweise vorzukonfigurieren. Das sollte man natürlich besonders bei Produkten machen, deren Eigenheiten man noch nicht in- und auswendig kennt, denn außerhalb der heißen Phase hat man Zeit und Ruhe und kann auch mal manche Dinge ausprobieren, die einen vielleicht nur akademisch interessieren. So fasst man Vertrauen zum Produkt und solches Wissen kann man sicher auch irgendwann mal wieder gebrauchen.
Ich baue neue Systeme - so vertretbar möglich - immer erstmal in einer Laborumgebung ("einem Lab") auf, das die Infrastruktur des Kunden möglichst 1:1 nachbildet.
Der Titel dieses Artikels ist ein alter Fliegerspruch, der in IT-Projekten natürlich auch seine Richtigkeit hat. Guckt Euch die Konfiguration der abzulösenden Systeme an, macht Euch Gedanken über den möglichen Weg vom aktuellen Zustand zum Zielzustand, definiert Euch Meilensteine und für den Kunden akzeptable Bauzustände, bei denen man im Falle eines Falles eine auch längere Pause einlegen oder ganz abbrechen kann. Auf den Originalzustand zurückrollen ist oft keine realistische Option oder macht bereits geleistete Arbeit zunichte. Nichtsdestotrotz sollte man sich diese Option als Manöver des letzten Augenblicks offen halten.
Informiert den Kunden über diese Planung und achtet darauf, dass er die Idee des Bauzustands versteht und nicht erwartet, dass in jedem Bauzustand jede Funktionalität unbedingt funktioniert, und dass er nicht meint, dass bloß weil Ping in die Welt und der Zugriff auf Sp**g*l Online wieder funktioniert, die Migration fertig abgeschlossen ist und alles was jetzt noch nicht funktioniert gleich eine Schlechtleistung des Dienstleisters darstellt.
Migrationen von einem alten System auf ein neues System sind etwas, was ich besonders gut kann. Ich bekomme es immer wieder hin, mit ein wenig Planung vorab die Migration mit deutlich kürzerer Downtime hinzubekommen, als es bei der naiven Vorgehensweise wäre. Dabei habe ich wenig Angst, einen Bauzustand mit vielleicht nichtmal sechzigprozentiger Funktionalität online gehen zu lassen, wenn mich das bei der Durchführung der Restarbeiten nicht behindert - frei nach "lieber ein wenig Funktionalität als gar keine".
Da mein "Lieblings"-Firewallhersteller seine Produkte Gott sei Dank Ende 2009 aus dem Support laufen lässt, habe ich in den letzten Monaten nicht nur ein Firewallmigrationsprojekt bei und mit Endkunden durchgeführt. Dabei ist natürilch das eine oder andere schiefgelaufen, und in der folgenden Artikelreihe "Zugschlus' kleiner Migrationsleitfaden" versuche ich diese neuen oder nicht mehr ganz so neuen Erfahrungen so aufzuarbeiten, dass vielleicht auch Ihr etwas davon habt.
Entgegen der landläufigen Meinung ist eine Migration übrigens erheblich komplexer und schwieriger als die Inbetriebnahme eines ganz neuen Systems ohne Vorgänger. Bei einer Migration hat man einen Ausfall eines Dienstes, von dem vielleicht Teile der Kundenorganisation abhängen, man muss Daten übernehmen, und hat es plötzlich und akut mit Befindlichkeiten von Benutzern und kleinen Fürsten zu tun, denen Funktionalität kurzfristig (im Rahmen der Umbauarbeiten) oder langfristig (weil das neue System vielleicht manche Dinge nicht mehr kann) verloren geht. Ein Projektstopp bedeutet bei einer Migration in aller Regel weitere Arbeiten, um auf den Ursprungszustand zurückzukommen, während man bei einer Neueinführung einfach alles stehen lassen kann.
Die Artikel sind mit "zkmlf" getagged und können jederzeit gesammelt aufgerufen werden. Es gibt auch einen RSS feed.
