Monthly Archives: June 2008

Xen auf Debian. Teil 1

Eigentlich wollte ich hier auch auf die Xen-Installation eingehen, aber dafür gibt es ja schon genug Anleitungen im Netz, auch auf Deutsch. Die meisten Anleitungen sind hoffnungslos veraltet, weil XEN sich einfach extrem schnell bewegt. Während man noch vor 2 Jahren viel zu konfigurieren hatte, wenn man ein Bridged oder Routed Setup haben wollte, muss man dafür heute nur noch eine Zeile in der Konfigurationsdatei ändern. Die meiner Meinung nach beste Anleitung für XEN im Internet ist die von Denny Schierz.

Für XEN würde ich auf jeden Fall lvm empfehlen, einerseits hat das den Vorteil der höheren Geschwindigkeit, andererseits ist man damit aber auch viel flexibler als mit dem traditionellen Partitionen. Allerdings werde ich auch das überspringen, weil Henrik Skupin schon eine tolle Anleitung dazu online gestellt hat. Ich gehe also davon aus, dass eine LVM-Partition zur Verfügung steht und XEN zusammen mit den XEN-Tools installiert ist.

Im folgenden, ersten Teil soll es darum gehen, eine Basis zu schaffen für weitere Arbeiten. Wir erstellen also eine XEN-Instanz mit Debian und sichern diese Basiskonfiguration mit einigen grundlegenden Schritten ab. Dann machen wir daraus ein tar-Archiv und legen das Image beiseite, um davon dann jeweils beliebige Server zu erstellen, ohne immer wieder die selben Handgriffe durchführen zu müssen.

Beginnen wir ohne weitere Umschweife

Wir erstellen mit folgendem Befehl eine neue Xen-Instanz:
# xen-create-image --ip=[IP-Adresse] --hostname=[Hostname]

Das kann einige Minuten dauern, die Daten dafür werden aus etc/xen-tools/ geholt, allerdings kann man viele Parameter auch noch im Nachhinein noch ändern, die Konfigurationsdateien für die Instanzen liegen unter etc/xen/[name der instanz].cfg

Wir starten die Instanz mit
# xm create -c [hostname].cfg

wobei wir mit -c gleich eine Konsole für die Instanz bekommen. Natürlich kann man auch nachträglich noch auf die Instanz wechseln mit:
# xm console [hostname]

Erste Amtshandlung auf der neuen Konsole ist natürlich:
# apt-get update && apt-get upgrade

Dann noch:
# apt-get install locales
# dpkg-reconfigure locales

Um eine deutsche Tatstatur und deutsche Texte zu bekommen und ein abschließendes:
# tzconfig

Um auch die Zeitzone richtig zu setzen.

auf ntp für die Zeit können wir verzichten, weil schon einer auf dem Wirt läuft und es keine gute Idee ist, beide gegeneinander laufen zu lassen.

Damit ist die Instanz ganz grundlegend schon einmal eingerichtet. Ab jetzt folgen die Applikationen, um den Server abzusichern: Firewall, SIV, IDS

Beginnen wir mit der Firewall:
Zunächst müssen unsere Firewall-Regeln bei jedem Systemstart geladen werden. Dazu richten wir die Kpnfigurationsdatei ein, vergeben die entsprechenden Rechte und legen die Datei in die Runlevel-Verzeichnisse:

# touch /etc/init.d/firewall
# chmod 775 /etc/init.d/firewall
# update-rc.d firewall defaults

Die Datei muss jetzt aufgefüllt werden. Im Grunde sollte man natürlich immer nur die Ports offen lassen, die man tatsächlich auch verwendet. Nicht benötigte Ports also im folgenden einfach auskommentieren. Dazu ein Hinweis: Auch wenn man selbst keinen DNS-Server betreibt, muss der Port 53 UDP offen bleiben, damit solche Sachen wie “apt-get update” funktionieren.


#!/bin/sh
echo "initialisiere Firewall ..."
# Module laden
modprobe ip_conntrack_ftp
# Alles bisherige loeschen und nichts akzeptieren
iptables -F
iptables -X
iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -P FORWARD DROP
iptables -Z
iptables -N MYDROP
iptables -N MYACCEPT
#
# Loopback freigeben, fuer lokale Apps
#
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT
#
# Eigene Chains definieren (MYDROP/MYACCEPT)
#
iptables -A MYDROP -j LOG --log-level 3 --log-prefix "FW-DROP: "
iptables -A MYDROP -j DROP
iptables -A MYACCEPT -j LOG --log-prefix "FW-ACCEPT: "
iptables -A MYACCEPT -j ACCEPT
#
# Mitloggen, wenn invalid
#
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -m state --state INVALID -j MYDROP
iptables -A OUTPUT -m state --state ESTABLISHED -j ACCEPT
#
#
# ssh
iptables -A INPUT -p tcp --dport 22 -j MYACCEPT
iptables -A OUTPUT -p tcp --dport 22 -j MYACCEPT
# ping erlauben, selber pingen
iptables -A INPUT -p icmp -j MYACCEPT
iptables -A OUTPUT -p icmp -j MYACCEPT
# DNS als Client
iptables -A INPUT -p udp --dport 53 -j MYACCEPT
iptables -A OUTPUT -p udp --dport 53 -j MYACCEPT
# Webserver
iptables -A INPUT -p tcp --dport 80 -j MYACCEPT
iptables -A OUTPUT -p tcp --dport 80 -j MYACCEPT
# Mails, SMTP, POP, IMAP
iptables -A INPUT -p tcp --dport 25 -j MYACCEPT
iptables -A OUTPUT -p tcp --dport 25 -j MYACCEPT
iptables -A INPUT -p tcp --dport 110 -j MYACCEPT
iptables -A OUTPUT -p tcp --dport 110 -j MYACCEPT
iptables -A INPUT -p tcp --dport 143 -j MYACCEPT
iptables -A OUTPUT -p tcp --dport 143 -j MYACCEPT
# FTP nach draussen
iptables -A INPUT -p tcp --dport 21 -j MYACCEPT
iptables -A OUTPUT -p tcp --dport 21 -j MYACCEPT
#
echo "Firewall ist konfiguriert und aktiv"

Datei speichern und die Firewall starten. Vorsicht: ssh muss in jedem Fall erlaubt sein, sonst sperrt man sich im nächsten Schritt selbst aus ;)
# /etc/init.d/firewall start

Etwas unangenehm ist, dass die Firewall jetzt auf die Shell loggt. Wenn das System etwas unter Last steht, kann einen das leicht verrückt machen. Es reicht ja, wenn es in Syslog geloggt wird. Also ändern wir /etc/default/klogd und dort die Zeile
KLOGD=”-x”
in
KLOGD=”-x -c 4″
Abspeichern. Fertig.

Jetzt ist Tripwire an der Reihe. Tripwire ist ein System Integrity Verifier. Vereinfacht gesagt: Es stellt sicher, dass das System noch in dem Zustand ist, in dem wir es verlassen haben und zeichnet alles mit, was sich doch verändert hat und sich nicht hätte ändern dürfen/sollen.

Installation wie immer bei Debian:
# apt-get install tripwire

Dann in den Dialogen alles abnicken und die Passphrasen für die Keys und die Signaturen eingeben. Damit werden später die Konfigurationsdateien verschlüsselt, damit ein Angreifer nicht sehen kann, wie Tripwire konfiguriert ist und die Konfiguration auch nicht ändern kann. Sonst wäre das System ja nicht besonders sinnvoll. Da der local-key nach dem Hostnamen genannt wird – [hostname]-local.key –, muss er neu erstellt werden, wenn man die Instanz mit einem anderen Hostnamen startet. Das kann man bequem erreichen über:
# dpkg-reconfigure tripwire

Die Konfigurationsdateien liegen unter /etc/tripwire

twcfg.txt ist die Konfigurationsdatei und sollte gleich gelöscht werden, denn darin werden wir nichts ändern und Tripwire bezieht ja seine Informationen aus der verschlüsselten Konfigurationsdatei tw.cfg
Wenn man twcfg.txt doch noch irgendwann brauchen sollte, reicht einfach:
# twadmin --print-cfgfile > /etc/tripwire/twcfg.txt

Wichtig ist für uns die Policy-Datei twpol.txt. Hier wird festgelegt, was alles überwacht werden soll und was an Aktionen ausgeführt werden soll. Ich werde nicht auf den Inhalt der Datei eingehen. Hier ändern wir nur drei Einstellungen. Wir kommentieren folgende Zeilen aus:

/etc/rc.boot -> $(SEC_BIN) ;
Alles, was /root/ im Pfad trägt ( Z.B.: /root/.elm -> $(SEC_CONFIG) ; )
/proc -> $(Device) ;

Ersteres existiert unter Debian nicht, was zu Fehlermeldungen führt und letztere ändern sich zu häufig, als dass ein Logging sinnvoll wäre.

Das jetzt abspeichern und die Datei verschlüsseln. Das ist wichtig, sonst erkennt Tripwire die Datei gar nicht an:
# twadmin --create-polfile -S /etc/tripwire/site.key /etc/tripwire/twpol.txt

Anschließend wir die Policy-Datei gelöscht. Auch die kann bei Bedarf wiederhergestellt werden mit:
# twadmin --print-polfile > /etc/tripwire/twpol.txt

Jetzt initialisieren wir Tripwire.
# tripwire --init

Daraufhin können wir auch gleich eine manuelle Integritätsprüfung vornehmen:
# tripwire --check

Diese Prüfung wird zwar ohnehin täglich automatisch durchgeführt, aber man sollte sie auf jeden Fall nach jeder Änderung ausführen, um so nicht nach Tagen den Überblick zu verlieren, was man selbst geändert hat und was nicht. Da Tripwire den aktuellen Zustand des Systems mit einer Datenbank vergleicht, muss nach jeder Änderung am System natürlich auch die Datenbank aktualisiert werden (env LANG=C ist notwendig wegen eines Debian-Bugs, falls im Report UTF-8-Zeichen auftauchen):
# env LANG=C tripwire --update --twrfile /var/lib/tripwire/report/.twr

Es folgt eine Liste der Änderungen, die mit dem letzten –check übereinstimmen sollte. Vor jeder Änderung steht ein x in eckigen Klammern [x]. Wenn man dies belässt, wird die Änderung akzeptiert und die Datenbank aktualisiert, entfernt man das x wird die Änderung auch zukünftig angemeckert. Wenn man die Datei abspeichert, wird die Datenbank aktualisiert. Vorsicht: Der Report wird in Vi geladen. Der Editor wird mit ESC in den Befehlsmodus gesetzt, dann wird mit einem Doppelpunkt der Befehl eingeleitet. “wq!” speichert und schließt die Datei. Jetzt noch twpol.txt entfernen und Tripwire steht für uns Wache.

Es folgt als letzter Schritt Snort, ein Intrusion Detection System. Es hält zwar keine Angriffe von Außen ab, aber zumindest berichtet es uns darüber, was böse Hacker so alles versucht haben, um bei uns einzudringen. Installation wie üblich:
# apt-get install snort

Bei der Installation geben wir unsere eigene Aderesse als Heimnetz an, weil wir Snort nur auf dem eigenen Rechner laufen lassen wollen.
Vorsicht: Dies muss später geändert werden, wenn dieses Image auf einem anderen Rechner laufen soll. Die Konfiguration läuft über dpkg-reconfigure snort. Hier kann man auch angeben, wer die täglichen Report zu den Einbruchsversuchen erhalten soll,

Wir werden nichts weiter an der Konfiguration ändern, da Snort auch so schon recht sinnvoll eingerichtet ist. Allerdings ist das beste IDS nur so gut wie die Signaturen, die ihm zur Verfügung stehen. Unter Debian übernimmt das Oinkmaster. Installation:
# apt-get install oinkmaster

Jetzt müssen wir noch die Update-URL ändern, damit Oinkmaster Updates bekommt. Die Konfigurationsdatei liegt unter /etc/oinkmaster.conf
Die aktuelle URL lautet: http://www.snort.org/pub-bin/downloads.cgi/Download/comm_rules/Community-Rules-2.3.tar.gz

Und wir tragen Oink in die Crontab ein, damit wir das Aktualisieren der Signaturen nicht ständig von Hand vornehmen müssen. Das wird doch leicht lästig. Mir reicht ein Update pro Tag. Dazu fügen wir folgendes der Crontab unter /etc/crontab hinzu:
10 6 * * * root oinkmaster -o /etc/snort/rules/

Abschließend legen wir noch einen Benutzer an, mit dem wir uns von Remote anmelden können, damit wir ssh für Root sperren können.

# useradd -m [username]
# passwd [username]
# [passwort eingeben]

Jetzt noch die Konfigurationsdatei für ssh ändern. Unter /etc/ssh/sshd_config ändern wir die Zeile “PermitRootLogin yes” zu “PermitRootLogin no”.

Wir können uns dann mit einem unprivilegierten Benutzer anmelden und mit “su” zu Root wechseln.

Damit haben wir ein zumindest rudimentär eingerichtetes und abgesichertes System, das wir als Grundlage für praktisch jeden beliebigen Server verwenden können.

Als nächstes erstellen wir ein tar-Archiv vom Image. Dazu muss die Instanz herunter gefahren werden.

Wir erstellen ein Verzeichnis für das Archiv
# mkdir /var/xen-images

Wir erstellen einen Mount-Point für das Image
# mkdir /mnt/xen

Wir mounten das Image, wobei vg0 hier für die lvm-Partition steht und image-disk für den Namen der Instanz
# mount /dev/vg0/image-disk /mnt/xen/

Jetzt erstellen wir das Archiv. Das kann eine ganz Weile in Anspruch nehmen.
# cd /mnt/xen/
# tar pcfzv /var/xen-images/Image.tar.gz *

Das schöne daran: Egal wie groß man die Partition für die Instanz gewählt hat, alles wird in ein handliches Paket von etwas über 100 MB gepackt

Wir verlassen den Mountpoint und und löschen ihn dann wieder
# cd / ; umount /mnt/xen

Da wir nun eine immer gültige Ausgangsbasis für neue Server haben, entfernen wir die bisherigen Installationsmethoden aus der xen-tools-Konfigurationsdatei.
In /etc/xen-tools/xen-tools.conf kommentieren wir folgende Zeile aus:
debootstrap = 1

Ab sofort können wir neue Server ganz einfach anlegen mit
# xen-create-image --tar=/var/xen-images/Image.tar.gz --ip=[ip -Adresse] --hostname=[hostname]

Wenn wir eine neue Instanz mit diesem Image starten, müssen wir noch einen neuen localkey für Tripwire erstellen:
# dpkg-reconfigure tripwire

und dann die alten Datenabanken löschen aus /etc/tripwire und /var/lib/tripwire

Wir müssen auch die IP-Adresse, auf die Snort achten soll, vorgeben
# dpkg-reconfigure snort

Das ist der Basis-Server. Jetzt kann man natürlich nach belieben einen MTA, Datenbank- und Webserver installieren und all die Dienste, die einen Root-Server erst so richtig interessant machen. Darauf gehe ich dann im nächsten Teil ein.

Linux-Server mit Debian und Xen

Vor einiger Zeit habe ich einen Root-Server bei dem wirklich hervorragenden Hoster Hetzner gemietet. Für 50 Euro im Monat bekomme ich einen Dual-Core Athlon mit 2 GB RAM und 2×350 GB Festplatte. Der Arbeitsspeicher ist etwas knapp, aber dafür ist der Service drumrum erstklassig und die Hotline verzichtet nicht nur auf eine teuere Nummer, sondern ist sogar erreichbar und hilft weiter! Jedenfalls habe ich den Server schon vor einer Weile gemietet und bin erst kürzlich dazu gekommen, ihn richtig einzurichten. Ehrlich gesagt, wusste ich vorher kaum etwas über die Einrichtung und Administrierung eines Servers, bisher hatte ich immer nur mit Workstations zu tun gehabt und war auf dem Server immer nur als User aktiv gewesen. Nur eins stand für mich fest: Debian sollte es sein. So kam ich dann auf das Buch von Eric Amberg: Linux-Server mit Debian GNU/Linux. Eigentlich hatte ich gar nicht vor, ein so umfangreiches Buch zu kaufen (850 Seiten!), aber die Bewertungen auf Amazon gaben dann den Ausschlag: 13 Bewertungen, alle extrem positiv und nicht mal die klitzekleinste Kritik. Zu Recht, wie sich gezeigt hat, die 45 Euro sind definitiv gut investiert. Ich hab auch schon so einige Bücher zu technischen Themen hinter mir und muss sagen: Das hier ist wirklich das beste! Ganz im Gegensatz zu anderen deutschsprachige Autoren, hat Eric Amberg keine Angst davor, locker daher zu schreiben, statt nur sachlich trocken und spröde. So hält man dann auch 850 Seiten durch und wird am Ende mit umfassenden Wissen belohnt, dass ganz gut ausreicht, um einen eigenen Server ins Internet zu stellen, ohne unsicher sein zu müssen, ob man auch an alles gedacht hat. Natürlich wird man mit einem Buch nicht zum Profi-Linux-Admin. Dafür ist das Thema zu komplex und zu weit verzweigt, auch das verschweigt Amberg nicht. Allerdings wird das bei den meisten Lesern auch nicht wirklich die Ambition sein, das Buch zu lesen. Jedenfalls habe ich jetzt ein gutes Gewissen, wenn ich meine Mails von meinem eigenen Mailserver abhole und weiß, dass ich kein offenes Relay produziert habe, und dafür musste ich nur einen Monat lang 1-2 Stunden am Tag opfern. Es geht ein großer Dank an Eric Amberg, so ein Buch auf Deutsch geschrieben zu haben, auf Englisch ist mir nichts vergleichbares bekannt.

So, da wir jetzt die (nicht bezahlte) Werbung hinter uns haben, zum eigentlichen Thema. Während ich also das Buch am durcharbeiten war (Past Progressive), kam mir der Gedanke, dass es viel zu schade wäre, den ganzen Server nur für eine Aufgabe zu nutzen. Man brauch wohl schon eine extrem große Seite, wenn alleine das CMS einen Dual-Core mit 2 GB in die Knie zwingen soll. Man kann mit so einem Root-Server ja so viele schöne Sachen anstellen: ein eigener Mail-Server, ein Wiki als Ersatz für Niklas Luhmann Zettelkasten, das eigene Blog und für Firefox natürlich die Website und das Forum. Jetzt sind das aber ziemlich viele Anwendungen, die da parallel laufen müssten und wie wir wissen, ist jeder Dienst eine potentielle Sicherheitslücke. Wenn jemand über eine Lücke in phpBB Root-Access bekommt, möchte ich nicht unbedingt, dass er auch gleich Zugriff auf alle meine Mails bekommt oder mir das Wiki löscht. Die Lösung: Virtuelle Server. Klar, auch das ist kein 100%iger Schutz, aber schon eine sehr, sehr hohe Hürde. In der Linux-Welt hat man wie immer die Qual der Wahl. VMware, OpenVZ, XEN, User-Mode-Linux und sicher noch einige andere, die mir gerade nicht einfallen. Ich hab mich für XEN entschieden. Zum einen, weil es freie Software ist, zum anderen, weil es derzeit wohl die populärste Wahl ist und man dementsprechend auch die meiste Literatur dazu im Internet findet. XEN ist nicht perfekt, wie ich inzwischen feststellen durfte, aber es ist okay für das, was ich damit tun möchte, denn das wäre:

1 Mailserver, auf den IMAP und POP3 Zugriff möglich ist. Ich möchte 10 GB Speicher für Mails und unbeschränkte virtuelle Aliase.

3 Webserver, einen für mein Blog, einen für ein privates Institut, das ich mitbetreue und einen für das Firefox-Projekt. Auf dem ersten läuft nur das Blog, auf den beiden letzteren soll Drupal installiert werden und auf dem Firefox-Server zusätzlich phpBB.

1 Wiki. Im Grunde auch ein Webserver, der allerdings nach außen hin gar nicht in Erscheinung tritt und hinter einem Passwort versteckt ist, das Wiki soll also mein privater Zettelkasten sein.

So wie es aussieht, sollen im Endeffekt also 5 einzelne Server auf der eigentlichen Hardware laufen, wobei 2 davon auch unter hoher Last noch ansprechbar (responsive) sein sollen. In den nächsten Tagen werde ich hier auch für mich selbst (oder besser: für mein zukünftiges ich) dokumentieren, wie man Xen installiert, einzelne virtuelle Server zum Laufen bekommt und ein Master-Image erstellt. Sozusagen ein komplett fertig eingerichteter Server, den man einmal erstellt und dann als Ausgangspunkt für weitere Konfigurationen verwenden kann.

Firefox 3, frisch eingetroffen

Inzwischen dürfte es auch der letzte mitbekommen haben: Firefox 3 ist raus. Endlich, möchte man sagen. Es war ein hartes Stück Arbeit für alle Beteiligten, gerade zum Schluss noch einmal, aber Firefox 3 ist ein Browser, auf den ich wirklich richtig stolz bin. Mag sein, dass ich nicht ganz unparteiisch bin, aber er dürfte derzeit der beste Browser auf dem Markt sein, egal auf welcher Plattform und das ist nicht nur meine Meinung. Also, runterladen: getfirefox.com

The localizers perspective

My name is Abdulkadir Topal. I’m a student of (computational) linguistics and German literature by day, but by night I’m the lead localizer for the German version of Firefox (sometimes it’s the other way around).

I know what you think (especially you devs out there): how boring! …translating the wording of a web browser from one language to another for others to use in their own language. Well, that’s how it may look from the outside, but actually it’s one of the most interesting things to work on.  And, if you care about HCI (Human Computer Interaction) or user experience, then this type of work can be even more interesting.

When we first stared, we had a very small user base for Firefox in Germany. We have almost 20 million  regular users of the German version. That means, that almost 20 million people read what I translated, every day! That’s huge, at least for Germany. By my estimation, you probably won’t find many German translators or authors with more readers. Granted, the words are not completely mine and there is not so much to read to begin with, but still, just thinking about it gives me the chills. And, it shows how far we have come. This very fact makes me very cautious when I have to decide whether to translate a string or just leave it in English, since our end users are more “main stream” and less technical than maybe 3 or 4 years ago.

Oddly enough, most of the time, my indicator of whether or not a translation is correct is my dad. He is a casual user, checking e-mail every once in a while, buying his flights online etc.  If he is happy, I know most of our users will be happy. Thanks, dad!

I started with the localization of Firefox in the Winter of 2002. Back then very few knew about the project and only a handful people were actively working on it. I really had no idea about localization, but had a big desire to make the best translation possible for Firefox. Localizing Firefox from scratch took almost 2 full month, even though I heavily copied work done for the Mozilla Suite!! As you know Firefox grew bigger than any of us could have ever imagined and over the years our localization strategy changed as well.

Today I’m working on the localization with two other Mozilla partners. Alexander Ihrig (from Thunderbird) and Robert Kaiser (from Seamonkey fame). We check each others’ translation, preventing any spelling/grammatical mistakes or wrong translations from slipping through. Nothing is perfect and errors will slip through occasionally…and that’s when the big userbase comes in handy. Thanks to our nightly testers (yes, there are nightly tester of localized builds) very rarely do we get a report after a final version is released.

Since Firefox 1.0, all our translation work lands in the Mozilla code repository in CVS. Before we got privileges to check our work into CVS, a localizer like me had to finish the translation and then start bundling the work into a language pack.  Then, I had to find someone to upload it on the Mozilla servers and then link to the work from a website (like a personal blog or something like that). Since our German translation is now a part of the Mozilla code base on CVS, it’s much easier to coordinate the work. Everyone can see the last changes, what’s missing, and how the translation evolves. And, since there are nightly builds of localized versions, people don’t have to wait for the final language pack version to test our localization.

During the past years, our use of tools has also changed. We started with Mozilla Translator, but with the change to CVS, Mozilla Translator itself became pretty unusable. For Firefox 3, Alexander and I ended up using just plain text editors, and Robert used his heavily modified Mozilla Translator. Unfortunately it’s not so easy for us to switch to one tool as we all work on different platforms: Robert on Linux, Alexander on Windows, and me on Mac OS. Web apps could be an alternative, but their user experience is rather “limited”.  IMO, they don’t respond quickly enough to replace a desktop editor. Essentially, the only thing that a specialized editor could give us would be a translation memory, since we have no problem with the technical side.  But, this one benefit was not enough to endure all the other problems. Hopefully this will change for the time after Firefox 3 (see Verbatim).

Firefox 3 localization doesn’t only mean the product itself. An often neglected, but very important part, is the help system. For Firefox 3 it was decided to move the help both online and into a wiki, since the traditional help system seemed too inflexible for a project like Firefox. That meant a lot of work for us localizers and it would certainly not have been possible to make it in time with only 2 or 3 people.  Again, it really helps that Firefox is so popular. For the Help localization, I just had to ask for help on my blog and a got all the help I could ask for.

As you may already know, we have a market share of more than 30% for Firefox in Germany, which is really huge and a great indicator for how much people like our work. We are very proud of Firefox 3 and hope it helps even more people to just enjoy the web.

My dad loves it, at that’s usually a good sign ;)

Firefox 3 nicht mehr weit

Letzte Woche war ich mit Tristan, Schrepp und Tomcat in München zu einer kleinen Pressetour. Es ist definitiv keine gute Idee, sich München am Sonntag Nachmittag ansehen zu wollen, aber dafür waren die Interviews am nächsten Tag umso interessanter. Es gab die gesamte Bandbreite an Journalismus. Vom Technik-Journalisten, der den Unterschied zwischen Java und Javscript nicht kennt, bis zum absoluten Experten, der das Firefox-Projekt bis ins letzte Detail kennt und seit Jahren verfolgt. Zur letzteren Kategorie gehört mit Sicherheit Martin Jan Stepanek von Pressetext Österreich. Nach einem Interview mit Mike und Tristan, die er beide gehörig ins Schwitzen gebracht hatte, hatten wir ein Gespräch, das inzwischen beim Standard veröffentlicht wurde.

Nebenbei habe ich mit Henrik ziemlich heftig daran gearbeitet, Rechtzeitig mit der Übersetzung der Weltrekord-Website fertig zu werden. Klar, das ganze ist eine PR-Aktion, es geht einfach darum, den Start von Firefox 3 einem noch weiteren Kreis bekannt zu machen als den Technik-Freaks, die ja ohnehin schon meist den RC 1 nutzen. Wir haben so lange an Firefox 3 gearbeitet und es ist ein großartiges Stück Software dabei entstanden. Jetzt wollen wir natürlich, dass so viele Leute wie möglich auch von unserer Arbeit erfahren. Firefox 3 ist wirklich mit Abstand der beste Browser, den Mozilla je veröffentlicht hat. Er ist so gut, dass ich schon den RC 1 auf dem Mac meiner Eltern installiert habe. Bisher habe ich keine negativen Reaktionen erhalten und das ist für mich immer der Härtetest ;)