Mein zweites Mal St. Augustin für ein erstes Mal FrOSCon. Ganz in der Nähe unserer geschätzten Kollegen fand die zweitägige Konferenz zum Themenkomplex “Free Software and Open Source” an der Fachhochschule Bonn-Rhein-Sieg statt, es war nach den Jahren 2006 und 2007 die dritte Veranstaltung ihrer Art. Das fast schon symbolische und darüber hinaus drei Flaschen Club-Mate inkludierende Eintrittsgeld bot den Besuchern eine hervorragend organisierte Veranstaltung in einem angenehm überschaubaren Rahmen. Während die Aula der Fachhochschule die Stände diverser Projekte und Fachverlage beherbergte, fanden in den fünf genutzten Vorlesungsräumen meist parallel Vorträge für Entwickler, Administratoren und Nutzer freier Software statt, sowohl in Inhalt und Anspruch unterschiedlich zielgruppend.

Absolutes Highlight waren ohne jeden Zweifel die hochkarätigen Keynotes von Andrew S. Tanenbaum und Rasmus Lerdorf. Der durch seinen Disput mit Linus Torvalds legendär gewordene MINIX-Entwickler erwies sich als begnadeter, hochsympathischer Redner, dem es gelang, seine Konzepte und Ideen hinter dem prinzipientreu verfochtenen Microkernel-Konzept allgemein verständlich darzulegen. Auch der Mann hinter PHP wusste seinen Standpunkt zu vertreten und berichtete dem ungläubig kopfschüttelnden Zuhörer - nicht ganz ohne jedes Augenzwinkern - von den Bedrohungen unserer Umwelt in den Zeiten angeblich grüner IT. Vernichtende Benchmarks, anklagende Klassendiagramme und schockierende Syscall-Tabellen zeigten ein ums andere Mal das Gegenteil von skalierender Eleganz und somit ihre Wirkung: PHP frameworks kill your environment.

Doch auch die kleineren Perlen sollen nicht verschwiegen werden. Erkan Yanar weckte - eventuell ein wenig zu flapsig präsentiert - den administrativen Spieltrieb und lädt so zu Experimenten mit OpenVZ ein, während Sebastian Kügler KDE 4.1 und ein paar bescheidene Sneak Previews aus dem aktuellen SVN-Branch vorstellte. Praxisnahe Vorträge zu den Themen Proxytunnel von Dag Wieers und IPsec- und SSL-VPNs von Johannes Hubertz waren wie auch die Einführungen zu Nagios von Debian-Paket-Maintainer Alexander Wirt und dem Linux-HA-Clusterprojekt von Michael Schwartzkopff für den Berufsadmin quasi Pflichtprogramm. Offenbar waren eher Einsteiger in die jeweiligen Technologien und Tools als Zuhörer anvisiert, was mir neben manchem Denkanstoss oft leider nicht allzuviel neues offenbarte. Kollektive Seufzer und leidgeprüftes Kopfnicken lösten “Programmdokumentation leicht gemacht” von Carola Kummert und die unterhaltsame, mit “Systemadministration++” passend betitelte Präsentation (siehe auch adminzen.org) von Grml-Vater Michael Prokop aus. Auch hier waren es weniger die bahnbrechenden Neuigkeiten als vielmehr eine gruppendynamische Katharsis, welche durchaus zu neuen oder zumindest wieder ausgegrabenen Sichtweisen führen konnte. Etwas zuviel Inhalt wollte Fabrizio Manfredi in seinen Vortrag “How to design and build an inexpensive distributed file system” legen - nach einer Einführung in die Geschichte und Funktionsweise von OpenAFS blieb zu wenig Zeit für Hadoop, Ceph & Co. Den größten Funfaktor schliesslich brachten Geert-Dietger Hoffmann und Dag Wieers durch ihren Einsatz der Wiimote als Präsentationswerkzeug (Slides als PDF) mit, von wirklich praktisch über herrlich skurill bis hin zur vollkommen bespassten Sinnbefreiung.

Fazit: Die FrOSCon 2008 hat Spass gemacht. Neben den guten Talks beeindruckte das auf vielen gross gewachsenen Veranstaltungen verloren geglaubte Communityfeeling - oft versammelte sich ein nicht unerheblicher Teil der eigenen Blogroll zum gleichen Vortrag. Ein Wunsch zur Verbesserung des hohen Niveaus der FrOSCon bleibt das Kennzeichnen des inhaltlichen Anspruchs der Veranstaltungen - ob für Einsteiger, Intermediates oder illuminiert Initiierte. Sollte 2009 terminlich passen, bin ich auf jeden Fall gerne wieder mit dabei - ein dickes Lob an wahrhaft felsende Organisatoren und Helfer!

Eine Diskussion zu Xen und OpenBSD samt der scheu hervorgebrachten Meinung »Virtualization seems to have a lot of security benefits« provozierte einmal mehr einen weiteren Grundsatzerguss Theo de Raadts auf der öffentlichen Mailingliste des selbsternannt proaktiven Betriebssystems - in bekanntem Tonfall:

Diesem Kontext sei “An Empirical Study into the Security Exposure to Hosts on Hostile Virtualized Environments” zum Geleit gegeben. Das wenig überraschende Fazit: Auch virtuelle Maschinen möchten abgesichert und regelmäßig gepflegt sein. Unfehlbar sind sie nicht.

Mit ‘pf’, ‘pfsync’ und ‘CARP’ bietet OpenBSD eine vergleichsweise einfach zu administrierende, leistungsfähige Infrastruktur für das Failover redundant aufgesetzter Firewalls. Neben dem essentiellen Paketfilter ‘pf’ kümmert sich ’pfsync’ in diesem Kontext um das synchrone Statehandling der verschiedenen Nodes, um bei einem Wechsel des aktiven Firewallrechners im Cluster bestehende Netzwerkverbindungen aufrecht erhalten zu können. Der Einsatz des Common Address Redundancy Protocols CARP erledigt auf OSI-Schicht 2 und 3 dabei das eigentliche Procedere zur Hochverfügbarkeit, bei dem es klassischerweise zwischen MASTER- und BACKUP-Rollen auf Interface-Ebene unterscheidet. Eine detailreichere doch kurz gehaltene Übersicht bietet der Artikel “Firewall Failover with pfsync and CARP”.

Mit dem lange überfälligen Upgrade eines schon etwas in die Jahre gekommenen OpenBSD 3.7 Clusters auf Release 4.1 erhielt ich die einmalige Chance, meinen ersten OpenBSD-Kernelbug - wenn auch eher unfreiwillig in gewohnt unpassendster Situation - zu entdecken; das sequentielle Neuladen der Regeln des auf zwei Clusternodes verteilten Paketfilters führte nach wenigen Iterationen regelmäßig zum Absturz des Systems:

kernel: page fault trap, code = 0
Stopped at	pfsync_insert_net_state+0x472:	movl	0(%eax,%edx,4),%edx

Für Neulinge unter den digitalen Kammerjägern beschreibt die Kurzanleitung “How to debug kernel crashes” das Erstellen verwertbarer Bugreports für die Entwickler - in der Regel sollte man das fehlerhafte Verhalten jedoch zuerst unter Einsatz unmodifizierter GENERIC-Kernel reproduzieren können. Gesagt, getan; nun folgend das übersetzte Kochrezept.

Mit der Analyse des Trace-Outputs (im OpenBSD-Kerneldebugger ’ddb’ per ‘trace’ aufgerufen) kann die betreffende Funktion erkannt und im Quellcode schnell lokalisiert werden. Im Falle des gestorbenen Firewallnodes lässt folgende Ausgabe das Problem auf das Sourcefile ‘sys/net/if_pfsync.c’ zurückführen:

pfsync_insert_net_state(e34d4038,1,8,e34d4038) at pfsync_insert_net_state+0x472

pfsync_input(e3486a00,14,0,0,d0d1a034) at pfsync_input+0xa21
ipv4_input(e3486a00,d0d0e900,0,d08ab000,30) at ipv4_input+0x4f1
ipintr(d0640058,d30010,d08a0010,d08a0010,d08ab000) at ipintr+0x70
Bad frame pointer: 0xd08ace24

Erneut mit Debuginformationen kompiliert und disassembliert finden wir per ‘grep’ die fehlerhafte Funktion und addieren der dort angegebenen Speicheradresse den Offset aus unserem Trace-Output hinzu:

# grep “<pfsync_insert_net_state>” if_pfsync.dis
> 000002f4 <pfsync_insert_net_state>

Adam Riese addiert die Hexadezimalzahlen 0x2f4 + 0x472 zu 0x766 - genau in jener Zeile sollte sich innerhalb unseres disassemblierten Codes die Instruktion aus unserem Kerneltrap finden, und siehe da:

/usr/src/sys/net/if_pfsync.c:248
      756:       a1 b4 04 00 00          mov    0x4b4,%eax
      757:       R_386_32   pf_main_anchor
      75b:       66 c1 ca 08             ror    $0x8,%dx
      75f:       c1 ca 10                ror    $0x10,%edx
      762:       66 c1 ca 08             ror    $0x8,%dx
      766:       8b 14 90                mov    (%eax,%edx,4),%edx
      769:       89 55 ec                mov    %edx,0xffffffec(%ebp)
      76c:       e9 e5 fb ff ff          jmp    356 <pfsync_insert_net_state+0x62>
      771:       8d 76 00                lea    0x0(%esi),%esi

Damit haben wir die genaue Zeilenangabe des betreffenden Codeteils innerhalb der Funktion ‘pfsync_insert_net_state’ gewonnen, welche wir schon im Sourcefile ‘sys/net/if_pfsync.c’ festmachen konnten. Mit etwas Kontext sprechen also alle Indizien das folgende Konstrukt schuldig:

/*
* If the ruleset checksums match, it’s safe to associate the state
* with the rule of that number.
*/
if (sp->rule != htonl(-1) && sp->anchor == htonl(-1) && chksum_flag)
        r = pf_main_ruleset.rules[
            PF_RULESET_FILTER].active.ptr_array[ntohl(sp->rule)];
else
        r = &pf_default_rule;

Tiefer bewanderte Kerneldeveloper identifizieren hier eine Racecondition zwischen den Ruleset-Reloads beider Maschinen und stellen - keine 24 Stunden nach Meldung des Bugs - den ersten Patch zur Evaluation, der mittlerweile mit Revision 1.83 im CVS des MAIN-Branches enthalten ist - und auch hier erfolgreich unter Stress gesetzt wurde:

/*
* If the ruleset checksums match, it’s safe to associate the state
* with the rule of that number.
*/
if (sp->rule != htonl(-1) && sp->anchor == htonl(-1) && chksum_flag &&
    ntohl(sp->rule) <
    pf_main_ruleset.rules[PF_RULESET_FILTER].active.rcount)
        r = pf_main_ruleset.rules[
            PF_RULESET_FILTER].active.ptr_array[ntohl(sp->rule)];
else
        r = &pf_default_rule;

Das Fazit: Selbst durchaus unerfreuliche Vorkommnisse bieten bei Verfügbarkeit des Quellcodes das Potential, ungekannte Hintergründe zu verstehen und von Ihnen manchesmal Neues zu erlernen. Die Kommunikation mit den Entwicklern freier Software lässt darüber hinaus das gute Gefühl entstehen, selbst als einfacher Bote einer schlechten Nachricht beim Prozess der stetigen Verbesserung der quelloffenen Produkte positiv mitwirken zu können. Denn auch gerade davon lebt Open Source - den ausführlichen Bugreports dankbarer User.

Der akute Zeitmangel der letzten Tage erlaubt es mir erst jetzt, mit Abstand und Milde einen persönlichen Rückblick auf den vergangenen Linuxtag 2007 in Berlin zu notieren. Während die Fachpresse die weitestgehend positive Stimmung der Öffentlichkeitsarbeiter des Kongresses übernahm, schien die Bandbreite der Reaktionen bei Besuchern und Ausstellern etwas breiter gefächert und im Schnitt betrachtet eher deutlich dezenter ausgefallen zu sein. Vom schlechtesten Linuxtag aller Zeiten, auf dem Flurfunk gerüchteweise gar vom letzten seiner Art überhaupt, war vielerorts zu lesen und zu hören. Manch ein Aussteller beurteilte seine Anwesenheit im Vergleich zu Wiesbaden und Karlsruhe, aber auch nach wirtschaftlichen Gesichtspunkten bewertet schlicht als »katastrophal«. Nach zwei gelungenen Veranstaltungen in Karlsruhe besuchte ich 2007 erst zum dritten Mal die Fachmesse; die Premiere in Berlin verbuche ich mit Blick auf diesen überschaubaren Erfahrungsschatz im Vorgriff und Widerspruch zu den Veranstaltern eher als Fehlstart.

Mehr »

Nach dem soeben erledigten Kauf eines ansehnlichen Hartschalentrolleys für die weite Reise: Auch ich wohne heuer dem streitbar beschirmherr(sch)ten Linuxtag in Berlin bei. Anreise Donnerstags, Abreise am Sonntag. Zwischendurch und gerne auch danach: ein Meet & Greet mit (bisher) nur virtuell bekannten Netzgestalten. E-Mail, Instant Messaging (siehe Impressum) sowie IRC (mein schwer zu erratender Nick auf IRCnet/Freenode lautet “basquiat”) und Kommentarfunktion stehen jederzeit zur Kontaktaufnahme bereit - mal schauen, wie Mensch beWLANt sein wird. Ich freue mich auf die Gesichter hinter so vielen Namen und natürlich - nach unzähligen Jahren visagenfreier Kanalkameradschaft - den lauschmusikalischen Heiligendammdemonstrierer! Ach, und Camael: Bring’ Dein Gemüse in Sicherheit! :-)

... hätten es so garnicht realitätsfern durchaus bald sein können, wenn der geistig umnachtete Herr des Hauses - in Personalunion mit mir - nicht die falsche Sicherung zur falschen Zeit gezogen hätte (und all das nur, weil ein neuerdings etwas deviant agierender Durchlauferhitzer in den fachunkundigen Augen seines Besitzers damit eine potentielle Gefahrenquelle darstellt):

> uprecords
     #               Uptime | System                                    Boot up
----------------------------+-------------------------------------------------
     1   347 days, 13:05:27 | Linux 2.4.31-grsec       Wed Apr 19 08:11:37 2006
     2    12 days, 15:13:47 | Linux 2.4.31-grsec       Thu Apr  6 12:45:11 2006
->   3     0 days, 02:14:26 | Linux 2.4.31-grsec       Sun Apr  1 20:09:43 2007
----------------------------+-------------------------------------------------
1up in    12 days, 12:59:22 | at                       Sat Apr 14 11:23:56 2007
no1 in   347 days, 10:51:02 | at                       Fri Mar 14 08:15:36 2008

In knapp 18 Tagen wollte ich mit stolzgeschwellter Brust ein Loblied auf die Verlässlichkeit unseres regionalen Stromversorgers danieder schreiben, um unverblümt auf diversen Kanälen mit Laufzeit wider der Widrigkeiten zu protzen.

USV? For pussies. (But get me one of those).

Update: Neue Order des Vermieters: Spül- und Waschmaschine nicht zeitgleich betreiben; als Hausgemeinschaft das kollektive Warmduschen möglichst unterlassen. Der Hauptsicherungen wegen. Oder so.

Der offizielle Linux-Download des Last.fm-Players ist mittlerweile doch reichlich angestaubt: Aktuell wird auf den Seiten des sozialen Musik-Netzwerks die Beta-Version 1.0.0 feil geboten, etwas verschämt versteckt sich dort auch ein Build der Version 1.1.3.0 für Ubuntu Edgy. Wer wie ich mit eben jener eher weniger Glück hatte - die Soundkarte meines Thinkpads ließ sich über Alsa nicht korrekt einbinden - dem könnte das inoffizielle und garantiefreie Kompilat (may rape your cat and burn down your house) von Alberto Garcia helfen, welches zusätzliche Patches beinhaltet. Works for me, und so lausche ich wild hypfend derweil Roni Sizes Razorblade Switchblade auf meinem persönlichen DnB-Radio-Stream.

Natürlich lädt mein Last.fm-Profil zum musikalischen Stalken ein. Wer mit Last.fm eine der freudebringendsten Netzzweipunktnull-Applikationen noch nicht kennt, sollte sie jetzt kennen lernen.

Es wiederholt sich und passiert immer in den unpassendsten Momenten: das regelmäßige Stocken der Verbindung beim Einsatz des Madwifi-Treibers unter GNU/Linux. Der Grund dafür ist simpel, wird aber manchem schon eine stundenlange, ergebnislose Fehlersuche beschert haben - denn Schuld sind oft keine zickigen Access Points oder fehlerbehaftete WPA-Konfigurationen, sondern ein im Abstand von wenigen Minuten durchgeführter Hintergrundscan des Treibers.

Der Aufruf von iwevent hilft hier bei der Lokalisierung des Problems. Folgen auf regelmäßige Aussetzer ebenso regelmäßige Rückmeldungen des Hintergrundscans, so ist der Verursacher in der Regel gefunden:

root@thinkpad:/home/basquiat# iwevent
Waiting for Wireless Events from interfaces...
16:06:06.670110   ath0     Scan request completed
16:11:35.885831   ath0     Scan request completed
16:16:56.914699   ath0     Scan request completed

Der Scan des Madwifi-Treibers lässt sich manuell deaktivieren, wobei ath0 an die jeweilige Benamung anzpassen ist:

root@thinkpad:/home/basquiat# iwpriv ath0 bgscan 0

Was bei einem Handover den reibungslosen Wechsel von Access Point zu Access Point für hyperaktive Konferenzteilnehmer oder rastlose Studenten sicher stellen kann, nervt spätestens im Heimbetrieb, wenn die Musik im Medienstream stottert und die SSH-Session immer wieder für Sekunden einzufrieren scheint. Die beste Voreinstellung? Eine zielgruppenabhängige Frage. Kanalmitinsasse Dennis liefert zumindest für Freunde des IBM’schen Denkblocks interessante Ansätze: Nutzen wir den HDAPS-Sensor zur Bewegungsmessung, um Cybergeeks auf Wanderschaft als solche zu identifizieren, können wir den Hintergrundscan entsprechend aktivieren oder deaktivieren - verändert sich die Position des Notebooks nachhaltig, erscheint die Notwendigkeit eines Handovers wahrscheinlicher als im stationären Fixbetrieb.

Wer also schmeisst nun seinen gcc an und erfüllt den Wunsch des werten Kollegen nach einer netten Erwähnung seiner Person im printk() Format-String (ja, die Integration in eine Userlandapplikation wie dem NetworkManager erschiene natürlich weitaus passender)? Und überhaupt: GPS, anyone?

Madwifi nennt sich der Open Source Gerätetreiber für WLAN-Chips der Firma Atheros, wie sie nicht nur in meinem IBM Thinkpad verbaut werden. Heise berichtet nun über eine kritische Schwachstelle, die es Angreifern unter bestimmten Voraussetzungen erlaubt, fremden Code in das System einzuschleusen - und diese Voraussetzungen sind so exotisch nicht:

Eine fehlerbereinigte Interims-Version 0.9.2.1 existiert bereits, mit dem regulären Erscheinen des Nachfolgers 0.9.3 wird Ende nächster Woche gerechnet. Das Originaladvisory kann auf der Madwifi-Mailingliste eingesehen werden. Update!

Durch eine Abteilungsauflösung innerhalb eines großen Industriebetriebes in Mannheim - es wurde in weniger lohnintensive Länder verlagert - fielen ein 21“-Röhrenmonitor der Marke ELSA sowie eine ”Dual Head"-fähige Grafikkarte von Matrox in meine experimentierfreudigen Hände. Als bekennender Deskmodder galt es natürlich sofort, die Stabilität des Schreibtisches durch Hinzufügen eines zweiten Großbildschirms zu testen, um so Xinerama evaluieren und mit gigantischen 3200x1200 Pixeln protzen zu können. Das Setup als solches sieht wie folgt aus und sorgte erstmal nur für resignierendes Kopfschütteln seitens der weiblichen Hausbewohnerschaft:

Die Grafikkarte, eine Matrox G45+MDHA32DB, erlaubt den Anschluß zweier VGA-Monitore, die es trotz ihrer spärlichen Speicherbestückung von 32MB mit jeweils 1600x1200 Pixeln bei 85Hz befeuern kann. Der Bitknappheit ist bei solchen Auflösungen ein Wegfall jeglichen direkten Renderns geschuldet, zumindest bei alltagstauglichen Farbtiefen - der verfügbare Buffer ist schlicht zu klein. Xinerama - die komfortabelste Möglichkeit, mit zwei (oder mehr) Screens zu hantieren - unterstützt als Xorg-Erweiterung prinzipiell kein DRI, bietet dafür aber gegenüber dem karteninternen Mergen der Screens handfeste Vorteile: so maximieren Fenster wahlweise nur in einem Bildschirmbereich, entsprechend vorbereitete Programme und Desktopmanager bieten darüber hinaus entsprechend weitere Funktionalitäten an, die das Leben in den neu erschlossenen Weiten leichter machen.

Die Konfiguration von Xinerama und Xorg ist trivial. Relevante Ausschnitte aus meiner Konfigurationsdatei machen schnell deutlich, wie die Behandlung der verschiedenen Bildschirme unter Xorg zu verstehen ist:

Mehr »