Da ich da gerade zum x-ten mal drauf reingefallen bin:

Das udev der aktuellen Sysrescuecd zeigt nach dem Booten keine Devices für die LVMs an, obwohl diese korrekt erkannt wurden. Beheben lässt sich dies einfach, indem man die Volume Group einmal deaktiviert und dann wieder neuaktiviert:

vgchange -a n
vgchange -a y

Dann tauchen die LVMs wie gewohnt unter /dev/ auf.

Etwas schmunzeln musste ich ja gestern schon, als ich diesen Artikel bei Heise.de gelesen habe. Grinsen deswegen, weil in der Überschrift gleich zwei Namen auftauchen, an die ich unschöne Erinnerungen habe:

Zunächst mal ist da der Itanium – auch liebevoll Itanic genannt. Der Prozessor, der für den Tod der Alpha und des PA-Risc-Prozessor verantwortlich ist. Intel und HPs Plänen gemäß hätte der Itanium das 21te Jahrhundert der IT-Industrie einläuten sollten.

Von der sogenannten VLIW (Very Large Instruction Word) Architektur hatte man sich erhebliche Performancevorteile gegenüber einer Superskalaren CPU versprochen. Die Idee ist hierbei, dass nicht der Prozessor, sondern der Compiler entscheidet, welche Befehle gleichzeitig ausgeführt werden können. Nur hat dieser Ansatz nie so funktioniert, wie Intel sich das vorgestellt hat, einen Compiler, der den Optimalen Code für den Itanium erzeugt, gibt es bis heute nicht.

Darüber hinaus hat es Intel  jahrelang nicht geschafft, die eigene Roadmap für den Itanium einzuhalten. CPUs erschienen teilweise Jahre später als angekündigt, der Sprung über die GHz Grenze war langezeit nicht möglich. Die CPUs waren langsam, veraltet und stromfressend.

Der Todesstoß wurde dem Itanium jedoch von AMD, mit der Markteinführung des Opterons, versetzt. Mit der AMD-64 Architektur war ein 64 Bit-Prozessor zu einem Bruchteil des Preises eines Itaniums verfügbar, der zudem auch noch signifikant schneller war. Der eigentliche Vorteil von AMD-64 ist allerdings, dass der Prozessor nativ auch IA-32 (z.B. i386, Pentium)-Code ausführen kann. Dies kann der Itanium nämlich nur Mithilfe eines (langsamen) Emulators.

Die Firma Unisys ist andererseits auch ein nicht unumstrittener Player im IT-Feld. Natürlich erinner sich viele an die legendäre UNIVAC oder an die Erfindung von Perl (wobei sie dafür – meiner Meinung nach – eingesperrt gehörten). Zu den negativen Erinnerungen gehört jedoch das LZW-Patent, das jahrelang Anwender des GIF-Bildformates in Angst und Schrecken versetzte.

Das absolute Highlight war meiner Erinnrung nach jedoch eine Anti-UNIX, Anti-Linux Propagandakampagne, die Unisys zusammen mit Microsoft unter dem Titel “We have the way out!“, bei dem sich später herausstellte, dass es unter FreeBSD mit dem Apache Webserver lief. Na ja, war wohl nix. Das ist im übrigen auch meiner Meinung zum Itanium. Ich hoffe auf den schnellen Tod dieser Architektur.

Wie heißt es so schön: Was lange währt, wird endlich gut? Ich hoffe, selbiges trifft auch auf meine Studienarbeit zu, die nach fast einem Jahr Arbeit fertig geworden ist. Das ist schon ein tolles Gefühl, wenn man die Ergebnisse seiner Arbeit in gebundener Form in der Hand hält.

Im wesentlichen geht es in der Studienarbeit darum, wie erkannt werden kann, ob eine Webseite per HTTPS abrufbar ist. Aufgrund von Name-Based-Virtual-Hosting reicht es hierzu nicht aus, sich auf Port 443 zu verbinden, und zu hoffen, dass ein gültiges Zertifikat zurückkommt. In der Studienarbeit wurde daher ein Algorithmus entworfen, der auf Grundlage von Mustererkennungsverfahren die über HTTP abgerufene Webseite mit der über HTTPS abgerufenen vergleicht. Schwierig war hierbei vor allem, dass mittlerweile viele Webseiten dynamisch generiert werden, d.h. man kommt mit einem einfachen String-Vergleich nicht sonderlich weit. Hier kommt mein Algorithmus ins Spiel, der geschrieben wurde, um genau mit solchen Fällen umzugehen.

Studienarbeit: HTTPS Autodiscovery – Proaktive Erkennung von Sicherheitsverfahren.

Möchte man unter Linux die Partitionstabelle neu einlesen, ohne das System neu zu booten, so kann man dafür den Befehl partprobe verwenden. Dies ist z.B. sinnvoll, wenn man ein Raid Device auf einer ungenutzen Partition erstellen möchte, weil man hier den Partitionstyp auf Raid-autodetect ändern muss, weil man sonst die Fehlermeldung wie z.B. “mdadm: /dev/sda1 is too small: OK” erhält.

Im Rahmen meines Seminars “Netzsicherheit und Hackerarbwehr” ist mir ein Sicherheitsfeature im Linux Kernel begegenet, dem bisher noch relativ wenig Aufmerksamkeit gewidmet wurde. Das Feature heißt “Randomize VA Space”. Hierbei handelt es sich um Address-Space-Layout-Randomization (kurz ASLR). Bei jedem Start eines Programms, wird der Anfag des Stacks innerhalb des Address-Space (AS) dieses Programmes  nicht mehr wie früher statisch, sondern zufällig bestimmt. Bei IA-32 und X86_64 wird vom anfänglichen Stackpointer eine zufälliger Integer zwischen 0 und 2^13-1 abgezogen. Insgesamt gibt es also 8192 verschiedene Adressen, an denen sich der Stackpointer befinden kann.

Der Code hierfür ist architekturspezifisch und findet sich für IA-32 z.B. unter /usr/src/linux/arch/i386/kernel/process.c :

unsigned long arch_align_stack(unsigned long sp)
{
    if (!(current->personality & ADDR_NO_RANDOMIZE) && randomize_va_space)
        sp -= get_random_int() % 8192;
    return sp & ~0xf;
}

Dies alleine bietet noch keinen ausreichenden Schutz gegen Exploits. Die Gründe dafür kann man in meiner Seminarausarbeitung nachlesen. Allerdings ist das schon recht lästig, insbesondere, wenn man nicht weiß, dass es so ein Feature gibt und man ewig nach dem Grund sucht, wieso der schöne Exploit, den man gerade geschrieben hat, dauenrd abstürzt.

Abschalten kann man das Feature übrigens mit dem Befehl:

sysctl kernel.randomize_va_space=0

So, nachdem ich nun auch den Seminarvortrag gehalten habe (mit dem ich im großen und ganzen recht zufrieden bin) möchte ich hier auch die Folien zu dem Vortrag  sowie den Quellcode der von mir vorgeführten Demo online stellen.

Kristian Köhntopp hat einen sehr schönen Artikel über die Funktionsweise von InnoDB sowie der Bedeutung der einzelnen InnoDB spezifischen Optionen in der my.cnf geschrieben. Vielen Dank!

Im moment mache ich ein interessantes Seminar am Institut für Telematik an der Uni-Karlsruhe. Es geht um Hacking, Hackerabwehr, etc. Die Ausarbeitung habe ich mal online gestellt. Ich hätte btw. nie gedacht, wie viele Fehler man in 15 Seiten einbauen kann.

Lustiges Detail am Rande: Aufgrund von Befürchtungen der Fakultät hat dieses Seminar eine Zeit lang jedes Wochen seinen Namen gewechselt. Aus “Hacking und Hackerabwehr” wurde “Hacker und Hackerabwehr”… Im moment heisst sie “Netzsicherheit und Hackerabwehr”.

In http://justinsomnia.org/2007/08/search-engine-marketeers-are-the-new-script-kiddies/ beschreibt Justin Watt, wie er eines Tages fesstellen musste, dass seine Seite plötzlich aus dem Google Index verschwunden war. Durch einiges Nachforschen stellt er fest, dass ein Suchmaschinenspammer daran schuld ist – aber lest selbst, der Artikel ist sehr spannend und lesenswert.

Bei einem Kunden haben wir neulich einige Datenbanken auf einen neuen Datenbankserver umgezogen. Da wir aus Latenzgründen jedoch nicht alle Anwendungen auf den neuen Server umstellen konnten (der neue Server befindet sich im Rechenzentrum eines anderen Providers), haben wir uns entschlossen, eine Kopie der Datenbanken auf dem bisherigen Datenbankserver zu belassen.

Nun stellte sich allerdings das Problem, dass wir irgendwie beide Datenbanken synchron halten mussten. Replikation war leider keine Option, da wir den besagten Server bereits mit einem Backup-Server replizierten. Auch das periodische ziehen eines Dumps kam nicht in Frage, da wir die Daten nach dem Schreiben sofort auf beiden Systemen benötigten.

Wir entschieden uns daher, die Pflegeanwendung in beide Datenbanken gleichzeitig schreiben zu lassen. Damit es zu keinen Problemen mit inkonsistenten Datenbeständen zwischen den beiden Servern kommt implementierten wir das Schreiben folgendermaßen:

Starte Transaktion auf Server 1
Starte Transaktion auf Server 2

For QUERY in QUERIES:
    Führe Query auf Server 1 aus
    Führe Query auf Server 2 aus

If !ERROR:
    Commite Transaktion auf Server 2
    Commite Transaktion auf Server 2

Else:
    Rolle beide Transaktionen zurück

In unseren Tests lief alles gut, das Transaktionshandling funktionierte. Selbst bei provozierten Fehlern verhielt sich alles so, wie erwartet.

Kurz nach der Installation der Anwendung beim Kunden traten jedoch Probleme auf mit einem Fall, den wir leider vollkommen übersehen hatten: Durch einen unglücklichen Umstand war es möglich, auf Server 1 ein Insert-Query auszuführen, das auf Server 2 fehl. Eigentlich sollte hier unser Transaktionshandling eingreifen und die Änderungen rückgängig machen.

So weit die Theorie. In der Praxis hat das Rollback zwar durchaus die Änderung rückgängig gemacht, hat allerdings das AUTO_INCREMENT Value nicht wieder dekrementiert. Dies bedeutete nun, dass das AUTO_INCREMENT auf Server 2 eins niedriger war als das auf Server 1, was dazu führte, das alle weiteren Updates fehlschlugen, da nun alle von unserer Tabelle abhängigen Foreign Keys schief standen.

Die rettende Idee kam von einem Kollegen: Nach dem ausführen des Insert Statements auf dem ersten Server lesen wir nun mit LAST_INSERT_ID() den Wert der AUTO_INCREMENT Spalte aus und fügen diese explizit in den Set Part des Statements, das wir auf dem zweitem Server ausführen, ein. Somit laufen die IDs nicht auseinander und unser Tag und die Applikation war gerettet.