Natürlich habe ich mich mit SuSE lange Zeit wohlgefühlt, hauptsächlich wohl weil ich noch nichts anderes kannte und SuSE ja allgemein ein beliebter Anfängerfehler ist (oder war). Danach sprang ich, von einem Kollegen infiziert, in die kalten Fluten und beschäftigte mich eingehend mit Gentoo. Bis heute muss ich sagen, dass mir der Gentoo-Ansatz am besten gefällt. Das Portage-System ist natürlich durchaus mit den BSD-Ports vergleichbar und ein rundum angepasstes System ist damit perfekt möglich.

Für den Desktop-Einsatz jedoch eigenete sich Gentoo leider auf lange Sicht nicht. Gerade wenn man öfters mal spontan neue Programme benötigt, gibt es hier Stress. Möchte mann in einer Präsentation ein Programm zeigen, mit dessen Notwendigkeit man vorher nicht gerechnet hat, macht ein dreistündiger Kompiliervorgang nicht den allerbesten Eindruck. Mit dem GRP-Ansatz könnte man dieses Problem zwar lösen, jedoch gibt es da – meines Wissens – keine aktiven Entwicklungen.

Zuletzt war ich dann im Desktopeinsatz langjähriger Ubuntu-Benutzer. Im Serverbetrieb setzte ich stattdessen (größtenteils) auf Debian GNU/Linux. Im Prinzip war der Hintergedanke, grundsätzlich Debian-artige Systeme einzusetzen, da Paketverwaltung und Ähnliches hier einfach am schönsten ist. Ubuntu war die Alternative zu Debian testing, um ein halbwegs aktuelles System zu haben.

Spätestens mit Ubuntu 11.04 “Natty Narwhal” hat Canonical jedoch gezeigt, dass sie ihr Betriebssystem nun gezielt zerstören möchten. Unity und die restlichen damit verbundenen Patches kann man einem gesunden Menschen einfach nicht antun, und vor allem hinterlässt die Art und Weise der Entwicklung einen äußerst faden Nachgeschmack. Es sieht nämlich so aus, als sei Unity nur der Anfang einer langen Ära von Ubuntu-spezifischen Änderungen und Alternativlösungen. Vielleicht gibt es den einen oder anderen, der das möchte, aber ich persönlich möchte von der Community entwickelte, vernünftige Software.

Nachdem ich im letzten Jahr knallhart an Fedora gescheitert war (ieses System wollte bei mir einfach keine Grafik machen oder hängte sich alle 10 Minuten weg; die Fedora-Jungs bei den CLT hatten auch keine Ahnung wie sie das lösen sollten) habe ich dieser Distribution dann in den letzten Wochen noch einmal einen ausführlichen Besuch abgestattet. Zunächst war ich begeistert, da das System wirklich stabil und schnell lief und größtenteils recht unberührt aussah. Nach reiflichen Überlegungen war dann jedoch klar, dass man RPM und vor allem so etwas behäbiges und kaputtes wie yum dann doch nicht haben will. Die Antwort auf die Fragen der Paketverwaltung heißt apt.

Und nicht zuletzt ist da dann noch eine zugegebenermaßen eher religiöse Frage, nämlich die nach dem Maintainer einer Distribution. Aus meiner Sicht ist Debian schlicht die reinste Distribution. Rein bedeutet in diesem Fall, dass es weder einen historisch gewachsenen Bezug zu einem kommerziellen Anbieter (SuSE), einen kommerziellen Träger (Ubuntu) noch einen kommerziellen Supporter, der sich Sitze in einer Foundation kauft (Fedora) gibt. Natürlich wird auch Debian von großen Unternehmen wie HP oder 1&1 gefördert, jedoch gibt es hier keine Anzeichen von überdurchschnittlicher Beeinflussung durch die kommerziellen Interessen eines einzelnen Sponsors.

Bleibt ein ärgerlicher Punkt, nämlich der der in Debian stable deutlich veralteten Software. Jedoch kann man ja, wenn man es vernünftig tut, durchaus mit Debian testing arbeiten oder aktuellere Software händisch nachinstallieren. Für unerfahrene Anwender ist das sicherlich nicht die beste Option, für mich und meinen Benutzerkreis, der in der Handhabung und Wartung des Systems von mir betreut wird, ist es jedoch die beste Alternative.

Es steht hiermit, nach 9 Jahren, also fest: Debian soll und wird meine Heimat werden. Sowohl als Benutzer als auch als aktiver Kontributor.

Ich selber hatte vor einiger Zeit schon mal das Vergnügen, als ich in der aktuellen Ubuntu-Version 10.10 mal vorsichtig Unity testete. Nun kann man ja eigentlich erwarten, dass das Ding zumindest seinen Dienst tut, wenn es auch nicht die Standardoberfläche ist. Die QA einer Distribution sollte ja eigentlich sicherstellen, dass die vorhandenen Pakete keine wirklich abartigen Bugs enthalten. Und im Netbook Remix war Unity ja soweit ich weiß da ja schon Standard. Aber das ging gehörig schief. Nicht nur konnte ich das Teil absolut nicht bedienen, es ging auch alle paar Minuten in einem Segmentation Fault unter. Prost.

Und der schon genannte Usability-Test spricht dann auch irgendwie Bände. Hier mal ein kurzer Überblick über die detailierten Ergebnisse:

• 7 von 10 Testern brauchen Geschicklichkeitsübungen, um das Fenstermenü zu finden
• Das Menü Systemeinstellungen wird noch immer von allen Testern vermisst.
• Nur 5 von 11 Testern haben es geschafft das Launcher-Panel zu bearbeiten. Die meisten versuchten sich mit dem übriggebliebenen GNOME-Menüeditor, der keinem mehr was bringt.
• 8 Tester haben es nicht geschafft ein Icon zum Launcher hinzuzufügen. Warum weiß keiner so genau, das Ding hat sich halt gewehrt.
• 9 von 11 Testern haben es geschafft ein Fenster zu schließen. Das klingt jetzt toll, aber die anderen 9 haben sich nur von plötzlich auftauchenden Bugs oder verschwindenden Buttons nicht so sehr ablenken lassen wie die restlichen zwei.
• 5 von 11 Testern haben Unity beim Testen mal eben komplett gecrashed oder wurden von plötzlich auftauchenden, dauerfokussierten udn nie mehr verschwindenden Fenstern überrascht.

Besonders gefreut habe ich mich ja über diese Formulierung:

9/9 easily saved their LibreOffice Writer document. (P1 recovered
    amazingly well after trying to save "Letter to Mr Smith 08/04/11",
    and getting the vile response "Error stating file '/home/ubuntu
    /Documents/Letter to Mr Smith 08/04': No such file or directory").

Sehr hübsch. Aber lest das am besten alles nochmal selber, es lohnt sich .

Ich bin ja mal gespannt, ob die das noch rechtzeitig gefixt bekommen. Die letzten Releases waren ja drei Tage vor dem Termin auch noch vollständig im A****. Aber so heftig wie das ist, das kann eigentlich gar nicht mehr gut gehen. Bei Felix hat es Unity übrigens gar nicht auf die Reihe bekommen, irgendwas auf den Bildschirm zu malen (X.org und GNOME an sich funktionieren perfekt, wie man da als Unity scheitern kann ist mir ein Rätsel …).

Ubuntu wäre dann damit (außer vielleicht auf Tablets oder Netbooks) wohl vorbei, weil arbeiten kann man mit Unity sowieso nicht vernünftig (mit GNOME Shell dann in Zukunft übrigens auch nicht, aber das vielleicht noch eher). Momentan bin ich mit Debian eigentlich ganz zufrieden, auch wenn die ja “rock solid” immer noch mit “steinalt” übersetzen (da war neulich noch einer ganz stolz dass die jetzt die Security-Patches für Chromium 9 auf ihren Chromium 6 gebackported haben). Aber vielleicht kann man das ja aushalten …

Update: Hier übrigens auch ein netter Artikel dazu von Michael Kofler.

Da wir generell auf allen usneren Servern Fail2Ban betreiben, einen Log-Monitoring-Daemon, der auf Auffälligkeiten wie wiederholte fehlgeschlagene Logins und Ähnliches prüft und entsprechend reagiert. Eine Reaktion ist das bannen der angreifenden Adresse mittels iptables, eine weitere Aktion ist das Versenden eines detaillierten Reports per E-Mail.

Unsere erste Idee war nun, diese Reports zu aggregieren udn an ein zentrales Postfach zuzustellen. Erst einmal nur, um da zwischendurch mal einen kleinen Überblick zu bekommen, wie sich die Angriffe so verteilen. Portscans, SSH-Brute-Force-Angriffe und Ähnliches gehören ja zum “normalen” Grundrauschen im Internet, und da kommt täglich schon so einiges zusammen.

Als wir die Reports dann aggregiert hatten, kam die Idee auf, daraus doch gleich automatisch Abuse Complaints zu generieren und an die Provider der Angreifer zu senden. Da Fail2Ban zwar standardisiert, aber nciht wirklich maschinenlesbar mailt, ist dafür einiges an ekliger Parserei notwendig. Aber es funktioniert.

Und was soll ich sagen? Ich zitiere einfach mal Felix …

aber eins muss ich dir lassen das ist extrem geil was du da gebaut hast

Jo, danke . Was daraus geworden ist, findet ihr jetzt unter dem Namen Bashinators Abuse Central.

Ach ja, übrigens … die Skripts sind eklig. Die Website ist … also, hat ihren eigenen Charm. Und das ist ein Spaßprojekt . Ach ja, und SSI rockt.

Seit ein paar Tagen bekam ich dann von logwatch keine Mails mehr, was ich dann heute mal gedebuggt habe. Nun hat sich wohl irgendwann mal ein User mit irgendwelchem Random-Kram versucht einzuloggen (“3836jai)xoh)”). Unser Samba-Server ist so eingerichtet, dass er eine Logdatei pro User anlegt. Äh, das hat so mal Sinn gemacht … wirklich. Und deshalb gab es jetzt also eine Datei namens “log.3836jai)xoh)”. Und das fand logwatch gar nicht so lustig, denn logwatch wirft eine Liste der Logdateien die es so findet einfach so ohne sanity checks oder Quoting oder sonst was in die sh. Das resultierte dann in ein bisschen Fehlerausgabe und einem unsauberen Ende:

sh: -c: line 0: syntax error near unexpected token `)'
sh: -c: line 0: `cat /var/log/samba/log. 4023 /var/log/sa .........

Ist natürlich alles in allem ärgerlich, und irgendwie sollte man dieses komische Log-Setup auch mal wieder abschaffen. Aber dennoch, ich finde ein logwatch sollte das nicht einfach so tun. Nehmen wir mal an, ein User hätte sich aus Versehen als “; rm -rf /” oder “; poweroff” angemeldet. Dann hätte der Fileserver am nächsten Morgen um 6:25 sauber die Platte gewiped oder sich zur Ruhe gebettet. Echt unschön sowas …

Habe das jetzt mal an die Entwickler gefaxt, aber die lesen ihren Bugtracker offenabr nie. Mal schauen ob sie auf Mails reagieren … und der logwatch darf vorerst in seiner Hütte bleiben .

Update 1.3.2011: Bereits nach wenigen Stunden hatte einer der logwatch-Entwickler auf meine Mail auf der Mailingliste reagiert und einen Patch veröffnetlicht. Heute kriegte ich dann dank Google Alerts mit, dass Ubuntu was dazu in den Security Notices hat.

Und hier ist sie – meine erste offiziell entdeckte Vulnerability – CVE-2011-1018 (CVE | NVD | USN | …). Irgendwie bin ich ja dann doch so’n bisschen stolz. Darf ich jetzt eigentlich noch in die USA einreisen ?

Übrigens war mir bis gerade eben gar nicht klar wieso man da so einen Aufstand drum macht (gut, den macht man um jede Sicherheitslücke, aber es wirkt irgendwie erschlagend). Ich dachte ja das wäre nur in meiner komischen Samba-Konfig. mit den Benutzernamen im Log-Dateinamen so dramatisch, aber dann fiel mir auf, dass das sogar auf den meisten Linux-Distributionen mit Standard-Konfig. exploitbar ist. Viele Default-Konfigs setzen nämlich den NetBIOS-Namen des Clients in den Logdateinamen ein (log file = log.%m). Den kann man sich als Client im Prinzip ja auch selber ausdenken. Samba wird dann zwar unter Umständen sagen “Ne du, das Ding sieht komisch aus” oder “Häh, wer bist denn du?” – aber das wird es nicht nur dem Client mitteilen sondern das auch loggen. Und zwar wohin? Genau …

Update 4.3.2011: Die Debianer haben es dann heute mit DSA-2182-1 auch schon zu einem Advisory gebracht. Boah, sind die flott!

Nun wollen die anderen ja aber nicht immer ganz so, wie der Admin will, und deshalb muss ich auf dem neuen Ubuntu 10.10 maverick-Server natürlich Joomla (ebenfalls Krampf) supporten. Und in Ubuntu 10.10 ist PHP 5.3 an Bord.

Nun kursieren im Internet die kuriosesten Lösungen. Zum Beispiel könnte man PHP 5.2 selber kompilieren oder einfach aus den alten Repositories installieren, je nach gusto parallel zur neuen 5.3er-Version oder alleine. Beides möchte man so einfach eigentlich nicht. Ersteres könnte irgendwann die Selbstmordrate in der IT-Abteilung enorm steigern, letzteres rollt jedem sicherheitsbewussten BOFH die Fußnägel auf den Rücken.

Zum Glück hatte ich dank des Schneechaos bei der Bahn genügend Zeit, über die Problematik nachzudenken. Und kam auch tatsächlich zu einer Lösung,die ich persönlich für zwar nicht unbedingt resourcenschonend, aber sehr sauber halte: eine chroot-Umgebung mit Ubuntu karmic, darin ein Apache mit mod-php5 in der korrekten Uralt-Version. Und den dann nach außen geproxied.

Klingt kompliziert, ist aber eigentlich ganz einfach.

1. Zunächst installieren wir ein minimales Ubuntu karmic in /opt/karmic-chroot. Debian bzw. Ubuntu geben uns dafür alle nötigen Tools an die Hand. Gleichzeitig installieren wir die nötigen Webserver-Pakete mit:

   apt-get install debootstrap
   mkdir /opt/karmic-chroot<
   debootstrap --include=apache2,libapache2-mod-php5,php5-mysql karmic /opt/karmic-chroot

2. Eine kleine Stoplerfalle: Nun muss der DNS-Resolver so konfiguriert werden, dass auch Prozesse innerhalb der chroot-Umgebung Hostnamen auflösen können.

   cp /etc/resolv.conf /opt/karmic-chroot/etc

3. Nun muss der eingesperrte Apache an einen anderen Port gebunden werden als der öffentliche Server, außerdem lassen wir ihn (aus Sicherheits- und Übersichtlichkeitsgründen) nur auf dem lokalen Interface lauschen. Dazu msus die Datei /opt/karmic-chroot/etc/apache2/ports.conf editiert werden und ihr Inhalt durch diese Zeilen ersetzt werden:

   NameVirtualHost 127.0.0.1:8081
   Listen 127.0.0.1:8081

4. Als nächstes wird die VirtualHost-Konfiguration aus dem öffentlichen Webserver kopiert oder neu angelegt. Evtl. reicht auch die Standardkonfiguration, das hängt vom Geschmack und der schon vorhandenen Umgebung ab. Bei mir ist bereits ein VHost für Joomla! vorhanden, der die Seiten aus /srv/www/VHOST ausliefert. AUßerdem wird hier das mod_rewrite-Modul im chroot aktiviert:

   cp /etc/apache2/sites-available/VHOST /opt/karmic-chroot/etc/apache2/sites-available/default
   ln -s /etc/apache2/mods-available/rewrite.load /opt/karmic-chroot/etc/apache2/mods-enabled

5. Die Datei /opt/karmic-chroot/etc/apache2/sites-available/default wird nun so editiert, dass sie zum neuen Webserver-Setup passt. Das hängt wieder vom eigenen Setup ab, wichtig ist, dass die VirtualHost-Definition selber wie folgt lautet:

   <VirtualHost *:8081>

6. Das Web-Root wird in das chroot kopiert. Bei mir liegt es in /srv/www/VHOST:

   mkdir -p /opt/karmic-chroot/srv/www
   mv /srv/www/VHOST /opt/karmic-chroot/srv/www
   ln -s /opt/karmic-chroot/srv/www/VHOSTe /srv/www

   Die letzte Zeile erstellt einen symbolischen Link im alten Pfad, damit die Kollegen aus der Web-Abteilung nicht ganz so verwirrt sind …

7. Nun geht es an den öffentlichen Webserver. Die Proxy-Module werden mit

   a2enmod proxy proxy_http

   aktiviert und dann die Konfiguration des alten VirtualHosts durch die Proxy-Konfiguration ersetzt. Der Host bekommt keine Pfad-Konfiguration mehr, die Kern-Direktiven sehen dann so aus:

   ProxyRequests Off
   
   <Proxy *>
    Order deny,allow
    Allow from all
   </Proxy>
   
   ProxyPass / http://127.0.0.1:8081/
   ProxyPassReverse / http://127.0.0.1:8081/
   ProxyPreserveHost On

   Diese Direktiven leiten alle Anfragen an den eingesperrten Apache weiter. Besonders wichtig ist die letzte Zeile: Joomla wird die Basis aller internen Links durch die Adresse des lokalen Webservers ersetzen, wenn diese Zeile fehlt. Das funktioniert natürlich nicht, da der interne Server ja an localhost gebunden ist. Mit der Direktive ProxyPreserveHost setzt der Apache den Host-Header korrekt ein, so dass Joomla auch korrekte Links baut.

8. Nun sollten wir so weit sein, den Webserver im chroot starten und den öffentlichen neu starten zu können:

   chroot /opt/karmic-chroot /usr/sbin/apache2ctl start
   apache2ctl restart

9. Hat man sich von der Funktionsfähigkeit überzeugt, muss noch dafür gesorgt werden, dass der interne Apache auch beim Booten des Systems gestartet wird. Der Einfachheit halber bedienen wir uns hier des crons und fügen in /etc/crontab die Zeile

   @reboot root /usr/sbin/chroot /opt/karmic-chroot /usr/sbin/apache2ctl start

   ein.

Das war’s! Selbst die oft gefundenen Lösungen für das Link-Problem, bei denen meistens kuriose Patches oder Plugins eine Rolle spielen, ist durch die ProxyPreserverHost-Direktive gelöst.

Bleibt also nur noch zu sagen: Viel Erfolg!

Nachtrag

Einige Joomla-Module machten dann gerade noch Stress wegen des MySQL-Sockets. Klar, Joomla selber benutzt den TCP-Socket, aber einzelne Module müssen ihr eigenes Ding drehen. Ich möchte jetzt hier keine Namen nennen, aber dieses SchoolJoomla hat eindeutig den Platz 1 der Krampf-Rangliste erreicht …

Um das Problem nun zu lösen, müssen wir mysqld seinen Socket im chroot anlegen lassen. Dafür ersetzen wir in der Datei /etc/mysql/my.cnf alle Vorkommen des Pfades /var/run/mysqld/mysqld.sock durch /opt/karmic-chroot/var/run/mysqld/mysqld.sock. mysqld wird das Verzeichnis beim Starten anlegen.

Allerdings macht es uns Ubuntu dank Novell’s AppArmor nicht ganz so eifnach, so dass wir das Erstellen des Sockets an dieser Stelle noch erlauben müssen. In /etc/apparmor.d/local/usr.sbin.mysqld werden folgende Zeilen eingefügt:

/opt/karmic-chroot/var/run/mysqld/mysqld.pid w,
/opt/karmic-chroot/var/run/mysqld/mysqld.sock w,

und dann das Kommentar-Zeichen vor folgender Zeile in /etc/apparmor.d/usr.sbin.mysqld entfernt:

#include <local/usr.sbin.mysqld>

Zuletzt wird der AppArmor-Dienst und MySQL neu gestartet:

/etc/init.d/apparmor restart
/etc/init.d/mysql restart

Damit auch Prozesse in der Host-Umgebung, die sich nicht für die Konfiguration in der my.cnf interessieren, den Socket verwenden können, müssen wir noch dafür sorgen, dass wir den Socket in seiner Original-Location finden können. Weil /var/run jedoch bei jedem Booten geleert wird bzw. in einem tmpfs liegt, müssen wir /etc/rc.local wie folgt erweitern:

rm -rf /var/run/mysqld
ln -s /opt/karmic-chroot/var/run/mysqld /var/run/mysqld

und die Datei ausführbar machen:

chmod u+x /etc/rc.local

Damit sollten nun alle MySQL-Clients glücklich sein …

Dass die meisten elektronischen Übersetzer an irgendeinem Punkt immer ziemlichen Mist ausspucken, ist ja hinlänglich bekannt, aber der hier hat mich gerade meine Unterrichtsstunde gekostet.

Aufgabe:

Finde heraus, was der Slogan “Linux for Human Beings” bedeutet.

Schlau wie meine Kiddies ja sind, landet der Satz direkt in Google Translate …

Danke, Google, das war’s dann erstmal mit dem seriösen Unterricht …

P.S.: Um den anderen Klugscheißern zuvor zu kommen: ja, das ist case-sensitive …

Nun aber ans Eingemachte:

Leider muss ich einräumen, bei beiden Prüfungen schlechter als erwartet abgeschnitten zu haben, und auch schlechter als im letzten Jahr. DIe Ergebnisse sind leider nur durchschnittlich, was zum größten Teil wohl daran liegt, das sich meine Vorbereitung im Wesentlichen auf 30-60 Minuten am Vorabend im Hostel beschränkte .

Prüfung 201

Erreichte Punkte: 630/800

Prüfung 202

Erreichte Punkte: 640/800

Aber falls es jemanden beruhight, den man-Befehl kann ich bedienen …

Das Modul erlaubt es, das TUN/TAP-Device des Linux-Kernels als Objekt in Python zu verwenden. Dazu operiert es direkt per Filehandle auf das Kontrolldevice in /dev/net/tun und stellt Methoden zum Lesen und Schreiben auf das Interface bereit. Außerdem kann es einfache ifconfig-Kommandos für das Tun- bzw. TAP-Device ausführen, so dass das Interface sogar aus dem Script heraus konfiguriert werden kann.

Hier ein kleines Beispiel, das die aus dem Device ausgehenden Pakete bzw. Frams ausgibt (unspektakulär, aber es zeigt die einfache Verwendung des Moduls):

from pytap import TapDevice

dev = TapDevice()
dev.ifconfig(address = "10.0.0.1",
             netmask = "255.255.255.0"
            )

while 1:
    data = dev.read()
    print data

Hier ein paar Links:

• Launchpad-Homepage
• PyPI-Eintrag (Python Package Index)
• PPA mit Debian-Paket (Launchpad Personal Package Archive)

Das Modul ist die Voraussetzung eines größeren Projektes, von dem ich demnächst berichten werde.

Freitag, 20.8.2010

Nach einer halben gemeinsamen Urlaubswoche im verregneten Schwarzwald kamen Felix und ich dann im – ebenfalls verregneten – Bonn an. Das Hostel, in dem wir auch im letzten Jahr untergebracht waren, wollte uns erst zum regulären Check-In ab 17 Uhr herein lassen, und so machten wir uns erst einmal auf den Weg, um uns beim örtlichen McDonald’s mit etwas Essbarem zu versorgen. Zum Glück ergab sich daraus noch eine recht spannende Exploration der Innenstadt, was unserer immensen Langeweile entgegenwirkte.

Am Abend hatte ich dann noch ein paar Vorbereitungen für meine LPIC-2-Prüfung zu treffen.

Samstag, 21.8.2010

Für den einen oder anderen von uns stellt frühes Aufstehen bekanntermaßen eine ganz spezielle Herausforderung dar, doch trotzdem machten Felix und ich uns schon gegen 8 Uhr mit dem Fahrrad auf den 10km langen Weg zur Fachhochschule in St. Augustin. Nachdem wir unsere Event-Bags und Besucher-Badges erhalten hatten, wurden wir im Helfer-Office mit T-Shirts und Aufgaben versorgt.

Die Kollegen von CAcert stürzten uns natürlich sofort ins communitytypische Chaos, als die Frage aufkam, wo denn nun unsere Aussteller-Badges zu finden seien (Badge Nr. 3, für den unaufmerksamen Leser ). Doch auch dieses Problem ließ sich lösen (die sidux-Jungs hatten sich das Bündel unter den Nagel gerissen), und so nahmen wir unsere Rolle als Otto-Normal-Besucher ein und verschafften uns einen Überblick über die Aussteller.

Dass die FrOSCon-Organisatoren wie auch im letzten Jahr ein buntes und breit gefächertes Repertoir an Ausstellern zustande bringen würden, war wohl zu erwarten, doch dieses Jahr warteten sie mit einem besonderen Gimmick auf: Google Inc. höchstselbst fand den Weg nach St. Augustin und stand Interessierten Rede und Antwort. Natürlich gab es hier auch nette Merchandising-Produkte, von T-Shirts über (übrigens sehr nervige) Anstecknadeln und Hologramm-Schreibblöcke bis hin zu einem USB-Solarladegerät, das unter allen Teilnehmern eines Quizzes verlost wurde. Die Google-Jungs (und Mädels) scheinen also nicht nur online für bunte und aufwändigen Content zu stehen, sondern auch einiges für geekige Werbeartikel übrig zu haben. Dass mich das erneut positiv von dem kalifornischen Unternehmen überzeugt, dürfte die meisten Leser nicht weiter wundern; ebenso wenig, dass zumindest der nervige Google-Pin Felix in Angst und Schrecken versetzte. Schließlich wusste er um meinen Hang zum digitalen Kitsch und die Auswirkungen, die dies auf den Grad seiner regelmäßigen nervigen Belastung haben wird .

Zur Mittagszeit rief Ulrich zum CAcert Support MiniTOP, meinem ersten offiziellen Meeting in der neuen Rolle als Support Engineer. Auch mein Job als Co-Auditor wurde hier manifestiert. Spätestens wenn meine E-Mail-Signatur nicht mehr in das Eingabefeld des Thunderbirds passt, soltle ich aufhören, neue Ämter bei diesem verein anzunehmen .

Im Laufe des Tages fanden natürlich auch meine beiden diesjährigen LPI-Prüfungen (201 und 202) auf dem Weg zur LPIC-2-Zertifizierung statt. An dieser Stelel bedanke ich mich noch einmal ganz herzlich beim Förderverein des Leibniz-Gymnasium Remscheid für das Sponsoring dieser Prüfungen. Bei beiden Prfungen konnte ich 90% der Fragen beantworten und bin sehr zuversichtlich, in ein paar Tagen das Zertifikat als Intermediate Level Administrator im Briefkasten zu finden.

Um den sozialen Aspekt solcher Konferenzen nicht zu vergessen, fand abends im Anschluss an den ersten Konferenztag (und meine Aufsichts-Schicht an der Kinder-Hüpfburg) das Social Event in Form einer großen Grillparty statt, bei der Felix und ich mit einigen anderen Helfern auf der richtigen Seite des Grills eingeteilt waren . Es gab alles von Steaks und Würstchen bis hin zu vegetarischen Grill-Objekten (Grillkäse ist gar nicht so komisch, wie er klingt !), und auch hier zeigte sich das enorme Organisationstalent der FrOSCon-Crew in einer absolut guten Versorgung mit allem, was dazu gehört.

Da wir noch einen weiten Weg zum Hostel nach Bonn vor uns hatten und beide recht müde waren, verpassten wir leider den Anschnitt des FrOSCon-Geburtstagskuchens. Stattdessen verirrten wir uns desnachts noch gehörig in den Straßen der Bonner Vororte, bis Felix (dessen Orientierungssinn in dieser Nacht übrigens auch nicht von dem des bei ihm so beliebten “blinden Chinesens” entfernt war) die richtige Rheinbrücke wiederfand.

Sonntag, 22.8.2010

Helfer-Jobs halten fit – denn dass Felix eines mogens ungeduldig auf mich warten würde, hätte ich in meinen kühnsten Träumen nicht erwartet. Schon vor 9 Uhr nahmen wir den Helfer-Eingang der zum Messegelände umfunktionierten Fachhochschule und bekamen gleich unsere ersten Jobs des Tages (nebst frisch gewaschenem Helfer-Shirt). Felix durfte diTageskasse hüten, während ich den Netzwerkproblemen der Mensa (des großen Stände-Bereichs) hinterher telefonierte und den CAcert-Stand für die heutige Runde von Assurances vorbereitete.

Heute erhielt ich beim Mittagessen meine persönliche CAcert-Support-Einführung von Joost. Einfach unglaublich, mit was für Quark man da belästigt wird. Interessiert es mich wirklich, ob Netscape 3 im Jahr 2010 noch korrekt mit CAcert funktioniert? Und ist das überhaupt meine Aufgabe? Ebenfalls spannend wurde es dann bei zwei weiteren co-audited Assurances, bei denen sich wieder einmal herausstellte, dass die Privacy Policy von so gut wie keinem Assurer wirklich verstanden wurde.

Um 17 Uhr besuchte ich dann mit Felix meinen ersten (und einzigen) Vortrag an diesem FrOSCon-Wochenende, nämlich einen Talk über GNOME 3. Auch wenn sich im letzten Jahr viel getan hat, bin ich von den Neuerungen noch immer nicht überzeugt und kann mich mit der Idee der GNOME-Shell in keinster Weise anfreunden. Zum Glück haben sich die Entwickler gerade noch rechtzeitig gegen ein Release im September entschieden und die Entwicklungsphase um weitere 6 Monate verlängert.

Danach begann das allgemeine Abbauen. Schließlich musten die Mitglieder der FH ihr Lehrgebäude am Montag morgen wieder in dem Zustand vorfinden, in dem sie es der FrOSCon-Crew übergeben hatten. Teilweise gab es von diesem Zustand sogar eine recht brauchbare Dokumentation, nur an der Tischordnung der Mensa scheiterte es (wie wohl jedes Jahr) etwas. Es wurde zwar nach den Erfahrungen im letzten Jahr ein Plan angefertigt, dieser ließ sich allerdings nirgendwo mehr finden.

Gegen 21 Uhr war alles fertig und Felix und ich um einige Kenntnisse über die “Backstage-Area” der Konferenz reicher. Besonders gerne hätte ich das Equipment der Video-Crew eingepackt, doch wäre mein Fahrrad damit bestimmt etwas überfordert gewesen …

Und heute Abend navigierte uns Felix auch fachgerecht zum Hostel zurück, während ich (natürlich) überhaupt nicht wusste, was Sache ist …

Fazit

Fast hätte ich jetzt einen Satz gebracht, der mit “Wie jedes Jahr …” beginnt. Doch für Felix und mich war es ja erst der zweite Besuch der FrOSCon. Und trotzdem: Von allen Konferenzen und Messen, denen ich in diesem Bereich bisher beigewohnt habe, ist und bleibt die FrOSCon die am besten organisierteste und freundlichste von allen. Nicht nur wegen der unverschämt günstigen Eintrittspreise, die von einem ganz besonderen Händchen der Crew für Sponsoren zeugen, sondern wegen der Offenheit, die sich besonders im gegensatz zu Veranstaltungen des CCC nicht auf die Themen der Vorträge sondern auch auf die gesamte Oganisation der Veranstaltung beschränken.

Auch im nächsten Jahr werden wir definitiv als Helfer dabei sein – und trotzdem werde ich brav meien Spende verrichten, um das Konzept der Crew weiterhin zu unterstützen!

Weitere Fotos findet ihr auf Flickr.

Der Schlüsselwechsel ist natürlich nicht ganz einfach, besonders, da mein alter Schlüssel sehr viele Signaturen hat. Daher habe ich die Transition nach einem geplanten Ablauf durchgeführt.

1. Erstellung eines neuen Schlüsselpaars mit allen wichtigen UIDs
   

   $ gpg --gen-key
$ gpg --edit xxxxxxxx
adduid
adduid
...
save

2. Signieren des neuen Schlüssels mit dem alten Schlüssel, um eine authentifizierte Verbindung herzustellen
   

   $ gpg -u yyyyyyyy --sign-key xxxxxxxx

3. Erstellen einer Transition Note, d.h. einer kurzen Textdatei, die eine Information über den Schlüsselwechsel enthält. Signieren der Notiz mit dem alten und dem neuen Schlüssel, um den Text zu authentifizieren
   

   $ gpg -a -u xxxxxxxx -u yyyyyyyy --clearsign transition-note.txt

4. Update der Signaturrichtlinie und Signatur mit altem und neuem Schlüssel, so dass alte Signaturen gültig bleiben
5. Versand von Benachrichtigungen an alle Benutzer, die den alten Schlüssel signiert haben, mit der Bitte, auch den neuen zu signieren. Signatur der Mail mit neuem und altem Schlüssel. (Tipp: geht komplett durch mit einem Bash-Oneliner …)
   

   
# (Hier jetzt etwas ausführlicher, damit es lesbar wird ...)

   # Public Keyring sichern
   $ cd
   $ mv .gnupg/pubring.gpg .gnupg/pubring.bak

   # Alten Schlüssel neu laden
   $ gpg --recv-keys yyyyyyyy

   # Signaturen des alten Schlüssels auflisten
   $ gpg --list-sigs | grep ^sig | grep -o '[A-F0-9]\{8\}' | sort | uniq > sigs.txt

   # Alle Signaturschlüssel laden
   $ gpg --recv-keys `cat sigs.txt`

   # Adressliste erstellen
   $ gpg --list-sigs yyyyyyyy | grep -o '<.*>' | sed -e 's/<//g' | sed -e 's/>//g' >mails.txt

   # Nachricht signieren
   $ gpg -a -u xxxxxxxx -u yyyyyyyy --clearsign transition-mail.txt

   # Nachrichten versenden
   $ for i in `cat mails.txt`; do mail -s "New GPG key - please sign" $i <transition-mail.txt.asc; done

   # Wiederherstellen des Schlüsselringes
$ mv .gnupg/pubring.bak .gnupg/pubring.gpg


6. Widerruf des alten Schlüssels und Publizieren des alten und des neuen Schlüssels
   

   $ gpg --edit yyyyyyyy
revkey
save
$ gpg --send-keys xxxxxxxx yyyyyyyy

Anmerkung: In der Konfigurationsdatei (~/.gnupg/gpg.conf) sollten die Optionen expert und ask-cert-level eingetragen sein. In den Aufrufen steht xxxxxxxx für die ID des neuen und yyyyyyyy für die ID des alten Schlüssels. Das System muss Mails nach außen verschicken können, außerdem muss ein Keyserver konfiguriert sein.

Morgen muss ich noch die Informationen auf der Website aktualisieren und auf die Signaturen warten, dann ist der Übergang abgeschlossen.

Zusätzlich habe ich auch im neuen Schlüssel Felix als Revoker hinzugefügt. Damit hat er die Möglichkeit, meinen öffentlichen Schlüssel durch eine spezielle Signatur seines privaten Schlüssels zurückzuziehen. Sollte ich also meinen privaten Schlüssel und alle Backups verlieren oder im kritischen Fall keinen Zugang haben, kann Felix die nötigen Schritte einleiten, um Signaturen meines Schlüssels zu devalidieren. Bitte gebt dieses Recht aber nur Personen, denen ihr am besten noch mehr als 100% vertraut, sonst wird es im Zweifelsfall nämlich etwas haarig …