Monthly Archives: March 2009

Firefox 3.0.8 ist fertig. WOW!

Firefox 3.0.8 steht seit Kurzem zum Download bereit, und ich muss sagen, ich bin absolut begeistert. Das Update war klassifiziert als “high-priority firedrill security update”, da am 25.3.2009 ein Exploit für eine Lücke veröffentlicht wurde, und Firefox somit offen angreifbar war. Vor zwei Jahren hatte Mike Connor auf einer Sicherheitskonferenz behauptet, dass Mozilla, wenn es sein muss, ein Update innerhalb von 10 Tagen bereitstellen kann, gemessen ab dem Zeitpunkt, da Mozilla von der Sicherheitslücke erfährt. Das ganze wurde bekannt als “10 Fucking days“, und Mike wurde nicht wenig dafür belächelt.

Mit diesem Release hat Mozilla es geschafft, in drei Tagen ein Update für eine Sicherheitslücke bereit zu stellen. Das bedeutet, Fehler analysieren, Patch erstellen, reviewen, Builds erstellen, testen und die Infrastruktur zum Release in Stellung bringen,  wir haben 180 Builds (bei 3 unterstützen Betriebssystemen mal 60 Sprachen). Ich finde das einfach phänomenal, Firefox ist kein kleines Projekt, jeden Tag verwenden gut 220 Millionen Anwendern diesen Browser, ein Update in dieser Größenordnung ist also keine Kleinigkeit, aber umso beeindruckender. Das ist eine gute Gelegenheit, allen Beteiligten einmal kollektiv auf die Schulter zu klopfen, nicht zuletzt auch dem deutschen Übersetzungsteam um Henrik Skupin, das die Releasenotes in so kurzer Zeit parat hatte. Herzlichen Glückwunsch zusammen, das macht mich stolz, am Firefox-Projekt mitarbeiten zu können.

Übrigens: die Lücke, die “Nils” letzte Woche gefunden, aber noch nicht veröffentlicht hatte, wurde auch gefixt. Safari und Internet-Explorer, die auch geknackt worden waren, sind weiterhin anfällig. Wieder einmal ein eindrucksvoller Beweis, das nicht die Anzahl der Sicherheitslücken zählt, sondern wie schnell sie gefixt werden.

Xen Addendum

Eigentlich war der XEN-Server mit dem 5. Teil abgeschlossen, aber eine Kleinigkeit fehlte doch noch: Monitoring und Statistiken.

Für mich sind hier drei Dinge wichtig:
1. Alle Services sollen zu jedem Zeitpunkt laufen. Falls etwas hängt, soll es automatisch neugestartet werden mit einer Nachricht an mich.
2. Ich möchte den Speicherverbrauch, die Netzwerk- und die CPU-Nutzung etc. grafisch aufbereitet haben, ohne sehr viel konfigurieren zu müssen.
3. Über vorliegende Updates möchte ich jeden Tag per Mail benachrichtigt werden.

Glücklicherweise gibt es simple Tools für all diese Aufgaben und die Installation ist schnell erledigt, aber zunächst eine kleine Hilfe, die hier etwas aus dem Rahmen fällt:

fail2ban

Das Accesslog meines Servers ist so überflutet von Crackern, die versuchen, per Brute-Force einen SSH-Zugang zu bekommen, dass es im Grunde unbrauchbar ist. Mir ist nicht ganz klar, warum das nicht standardmäßig auf maximal 10 Versuche pro IP limitiert wird, aber fail2ban ist das optimale Tool, um genau diese Funktion nachzurüsten. Ich beziehe mich hier größtenteils auf dieses sehr hilfreiche Tutorial.

Wir installieren fail2ban wie üblich über:
# apt-get install fail2ban

fail2ban legt seine Konfigurationsdateien unter /etc/fail2ban/ ab. Dort findet sich auch die Standardkonfigurationsdatei jail.conf. Wir editieren nicht diese Datei, sondern erstellen eine eigene Datei mit dem Namen jail.local, die jeweils die Einstellungen in jail.conf aufhebt (kennt jemand ein deutsches Wort für override?) also:
# nano /etc/fail2ban/jail.local

Jetzt müssen wir uns entscheiden, was wir alles überwachen möchten. Ursprünglich hat mich zwar nur ssh interessiert, aber wenn wir schon dabei sind, können wir ja auch gleich Apache, Postfix und Courier überwachen lassen. Die Syntax der Datei ist ziemlich simpel. Erst stellen wir mit “ignoreip” eine IP ein, die niemals geblockt wird, damit wir uns nicht aus irgend einem Grund selbst aussperren. Bantime gibt in Sekunden an, wie lange eine IP gesperrt wird, wenn sie einmal geblockt wurde, und “maxretry” bestimmt, wie viele Versuche standardmäßig erlaubt sein sollen, das kann aber pro Anwendung übergangen werden.

Darauf folgt der anwendungsspezifische Abschnitt, hier beispielhaft dargestellt an ssh:

[ssh]

enabled = true
port = ssh
filter = sshd
logpath = /var/log/auth.log
maxretry = 5

mit “enabled=true” legen wir fest, dass wir ssh überwachen möchten, “filter=sshd” bezieht sich auf die Filterdatei filter.d in /etc/fail2ban/, “logpath” gibt an, wohin geloggt werden soll und maxentry, wie viele Versuche möglich sind, bevor geblockt wird. Alles in allem also ziemlich einfach und logisch.

Meine Konfigurationsdatei sieht folgendermaßen aus:

[DEFAULT]

# “ignoreip” can be an IP address, a CIDR mask or a DNS host
ignoreip = 127.0.0.1 78.46.34.54
bantime = 600
maxretry = 3

# “backend” specifies the backend used to get files modification. Available
# options are “gamin”, “polling” and “auto”.
# yoh: For some reason Debian shipped python-gamin didn’t work as expected
# This issue left ToDo, so polling is default backend for now
backend = polling

#
# Destination email address used solely for the interpolations in
# jail.{conf,local} configuration files.
destemail = root@localhost

# Default action to take: ban only
action = iptables[name=%(__name__)s, port=%(port)s]

[ssh]

enabled = true
port = ssh
filter = sshd
logpath = /var/log/auth.log
maxretry = 5

[apache]

enabled = true
port = http
filter = apache-auth
logpath = /var/log/apache*/*error.log
maxretry = 5

[apache-noscript]

enabled = true
port = http
filter = apache-noscript
logpath = /var/log/apache*/*error.log
maxretry = 5

[vsftpd]

enabled = false
port = ftp
filter = vsftpd
logpath = /var/log/auth.log
maxretry = 5

[proftpd]

enabled = false
port = ftp
filter = proftpd
logpath = /var/log/auth.log
failregex = proftpd: \(pam_unix\) authentication failure; .* rhost=
maxretry = 5

[wuftpd]

enabled = false
port = ftp
filter = wuftpd
logpath = /var/log/auth.log
maxretry = 5

[postfix]

enabled = true
port = smtp
filter = postfix
logpath = /var/log/mail.log
maxretry = 5

[courierpop3]

enabled = true
port = pop3
filter = courierlogin
failregex = courierpop3login: LOGIN FAILED.*ip=\[.*:\]
logpath = /var/log/mail.log
maxretry = 5

[courierimap]

enabled = true
port = imap2
filter = courierlogin
failregex = imapd: LOGIN FAILED.*ip=\[.*:\]
logpath = /var/log/mail.log
maxretry = 5

[sasl]

enabled = true
port = smtp
filter = sasl
failregex = warning: [-._\w]+\[\]: SASL (?:LOGIN|PLAIN|(?:CRAM|DIGEST)-MD5) authentication failed
logpath = /var/log/mail.log
maxretry = 5

Da ich keinen FTP-Server betreibe, habe ich die Überwachung dafür abgeschaltet, die failregex-Einträge sind für Debian Etch angepasst, offenbar funktionieren die Standard-Einträge nicht. Jetzt bleibt uns nur noch der Neustart des Dienstes und wir können uns darüber freuen, dass Brute-Force-Angriffe so schwer werden, wie es normalerweise sein sollte:

# /etc/init.d/fail2ban restart

Monit

Das nächste Tool, das ich hier vorstellen möchte, ist Monit. Monit ist dazu da, Prozesse auf dem Server zu überwachen und Alarm zu geben, wenn ein Dienst nicht so arbeitet, wie er soll. In dem Fall kann Monit beispielsweise den Webserver neustarten und eine Mail an den Admin senden. Es ist natürlich nicht ganz so günstig, dass der Dienst auf dem Rechnern liegt, der kontrolliert wird, falls der Server komplett down ist, läuft natürlich auch kein Monit mehr, das einen benachrichtigen könnte, aber für kleinere Ausfälle ist es bestens geeignet.

Wir beginnen mit der üblichen Installation:

# apt-get install monit

Jetzt müssen wir die Konfigurationsdatei an unsere eigenen Wünsche anpassen. Sie befindet sich unter /etc/monit/monitrc. Da wir nicht das Original verändern wollen, machen wir eine Kopie davon:

# cp /etc/monit/monitrc /etc/monit/monitrc_orig
# nano /etc/monit/monitrc

Ich zum Beispiel möchte den SSH-Daemon, den Webserver, MySQL und Postfix für Mails überwachen. Außerdem möchte ich Zugriff auf eine grafische Oberfläche auf Port 2812 des Servers, und dort möchte ich mich mit admin als Benutzername und test als Passwort anmelden. Entsprechend sieht meine Konfigurationsdatei folgendermaßen aus:

set daemon  60
set logfile syslog facility log_daemon
set mailserver localhost
set mail-format { from: monit@zfik.de }
set alert root@localhost
set httpd port 2812 and
allow admin:zfik.de

check process sshd with pidfile /var/run/sshd.pid
start program  “/etc/init.d/ssh start”
stop program  “/etc/init.d/ssh stop”
if failed port 22 protocol ssh then restart
if 5 restarts within 5 cycles then timeout

check process mysql with pidfile /var/run/mysqld/mysqld.pid
group database
start program = “/etc/init.d/mysql start”
stop program = “/etc/init.d/mysql stop”
if failed host 127.0.0.1 port 3306 then restart
if 5 restarts within 5 cycles then timeout

check process apache with pidfile /var/run/apache2.pid
group www
start program = “/etc/init.d/apache2 start”
stop program  = “/etc/init.d/apache2 stop”
if failed host www.example.com port 80 protocol http
and request “/monit/token” then restart
if 3 restarts within 5 cycles then timeout

check process postfix with pidfile /var/spool/postfix/pid/master.pid
group mail
start program = “/etc/init.d/postfix start”
stop  program = “/etc/init.d/postfix stop”
if failed port 25 protocol smtp then restart
if 5 restarts within 5 cycles then timeout

Um den Webserver zu kontrollieren, schaut Monit, wie man hier sehen kann, unter example.com/monit/token nach, ob die Datei dort zu erreichen ist. Entsprechend erstellen wir ein Verzeichnis unter /var/www:

# mkdir /var/www/monit

und legen dort eine Datei an:

# echo "hello" > /var/www/monit/token

Jetzt müssen wir noch die Firewall so einstellen, dass der Port 2812 von Außen zugänglich ist.

# nano /etc/init.d/firewall

Hier fügen wir im Abschnitt Webserver den Port 2812 hinzu, der Abschnitt sieht dann folgendermaßen aus:

# Webserver
iptables -A INPUT -p tcp –dport 80 -j MYACCEPT
iptables -A OUTPUT -p tcp –dport 80 -j MYACCEPT
iptables -A INPUT -p tcp –dport 2812 -j MYACCEPT
iptables -A OUTPUT -p tcp –dport 2812 -j MYACCEPT

Nicht vergessen, die Firewall neuzustarten:

# /etc/init.d/firewall restart

Jetzt bleibt nur noch, Monit zu starten und so einzustellen, dass es bei jedem Systemstart automatisch mitgestartet wird. Dazu bearbeiten wir die Datei /etc/default/monit. Wir ändern den Wert startup zu 1 und CHECK_INTERVALS auf 60 oder auf die Anzahl der Sekunden, die man zwischen den Monit-Tests vergehen lassen möchte.

Zum Abschluss starten wir Monit:

/etc/init.d/monit start

Jetzt können wir uns unter www.example.com:2812 mit dem Benutzernamen admin und dem Passwort test auf einer Weboberfläche anschauen, wie lange die Dienste schon laufen, und ob es ein Problem gibt oder alles läuft, wie es soll.

Munin

Während Monit sehr praktisch ist, um sich über den Zustand bestimmter Dienste auf dem Laufenden zu halten, geht Munin darüber hinaus und bietet grafisch aufbereitete Statistiken über den Verlauf der CPU-Nutzung, die Speicherauslastung oder die genutzte Bandbreite. Meine Anleitung basiert im Wesentlichen auf diesem englischen Tutorial.

Wir beginnen mit der Installation:

# apt-get install munin munin-node

Als nächstes erstellen wir die Datei /var/www/munin und ändern die Gruppe zu munin

# mkdir /var/www/munin
# chown munin:munin /var/www/munin/

Jetzt müssen wir nur noch Munin neustarten:

# /etc/init.d/munin-node restart

Nach ein paar Minuten kann man die ersten Statistiken unter www.example.com/munin bestaunen.

Die meisten werden allerdings nicht wollen, dass jeder einfach so auf die Daten zugreifen kann. Wir vergeben also ein Passwort für das Verzeichnis. Dazu erstellen wir die Datei .htaccess in /var/www/munin:

# nano /var/www/munin/.htaccess

mit folgendem Inhalt:

AuthType Basic
AuthName "Members Only"
AuthUserFile /var/www/munin/.htpasswd
<limit GET PUT POST>
require valid-user
</limit>

Jetzt vergeben wir den Benutzernamen (admin) und das Passwort:

# htpasswd -c /var/www/munin/.htpasswd username

Das war’s schon.

Apticron

Das beste an Debian ist wohl, dass Updates wie auch die Installation von Paketen ziemlich unkompliziert über die Bühne gehen. Entsprechend muss man auch nur selten drüber nachdenken, ob man wirklich ein Update einspielen möchte. Das Problem ist vielmehr, dass man erst einmal wissen muss, dass es Updates für den eigenen Server gibt. Natürlich kann man sich dazu täglich auf dem Server einloggen und #apt-get update && apt-get upgrade ausführen, aber viel bequemer wäre es doch, bei anstehenden Updates per Mail benachrichtigt zu werden. Genau das leistet Apticron.

Wir installieren das Paket mit:

# apt-get install apticron

Bei der Installation wird man danach gefragt, in welcher Form man Benachrichtigungen erhalten möchte und die E-Mail-Adresse an die das gehen soll, ich entscheide mich hier für Text-Mail.

Mehr ist nicht nötig, damit bekommt man einmal täglich Bescheid über anstehende Updates. Klein, aber sehr hilfreich, um nicht mit veralteter Software dazustehen.

Das ist also vorerst der letzte Abschnitt des XEN-Servers, und ein Abschnitt, das im hervorragenden Buch von Erik Amberg leider fehlt. So wie in dieser Reihe dokumentiert, laufen auch die Server, die ich betreibe und auch der neue Firefox-Server wird nach diesem Muster installiert und eingerichtet.

Lift09, Heute ist die Zukunft von Gestern

Letzte Woche hatte ich das Vergnügen auf Einladung von Mozilla in Genf an der Lift-Konferenz teilzunehmen. Das Motto der Konferenz war “Where did the Future go?”, also: Wie hat man sich früher die Zukunft vorgestellt, was ist aus ihr geworden geworden, wie wird sie wohl werden? Es war das erste Mal, dass ich an einer Konferenz mit so offener Agenda teilgenommen habe und ich war unsicher, was mich dort erwarten würde.

Wer TED kennt, weiß wie solche Konferenzen aussehen und da Lift eine Partnerveranstaltung von TED ist, wurde auch genau das geboten: Eine Menge kluger Menschen, die über ein interessantes Thema in ihrem Leben sprechen. Die Idee ist simpel, aber enorm wirkungsvoll. Nach 3 Tagen ist man vollgesogen mit fantastischsten Ideen, Informationen und Bildern.

Im Gegensatz zu TED wurden hier alle Vorträge schon kurze Zeit später ins Netz gestellt. Hier sind sie, zur freien Verfügung für jeden. Und weil dem so ist, hab ich ein kleines Video zusammengestellt, dass mehr die Eindrücke unserer kurzen Reise wiedergibt als die einzelnen Vorträge:

Obwohl ich fast alle Vorträge interessant oder zumindest anregend fand, stachen einige ganz besonderes heraus, vielleicht weil der Vortragende etwas spezielles an sich hatte oder mich das Thema sehr gepackt hat.

Zum einen ist da David Rose zu nennen. Rose forscht zum Thema Ambient Devices. Damit sind Geräte gemeint, die immer da sind, uns immer zur Verfügung stehen, aber unsere Aufmerksamkeit nicht fordern. Ein klassisches Beispiel für Ambient Design ist die Wanduhr. Sie ist immer da, man kann mal eben kurz aufschauen, und hat die Info, die man braucht und kann weiter arbeiten, lesen etc.

In einer Welt, die immer komplizierter wird, sind es diese Dinge, die einem helfen, die Informationsflut zu bändigen. Sie liefern Informationen, wenn man sie braucht und halten sich ansonsten im Hintergrund. In diese Richtung geht auch eines seiner Prototypen: Der Regenschirm, der blau leuchtet, wenn es an diesem Tag regnen wird. Ich kann mir also den Blick ins Internet sparen, und weil der Schirm immer in der Nähe der Tür hängt, würde ich ihn nie vergessen, wenn ich morgens aus dem Haus gehe, auch wenn es am Morgen noch nicht regnet.

Rose hat das mit dem Schwert von Frodo verglichen, das blau leuchtet, wenn Orks in der Nähe sind. Im Grunde heißt das, das Objekt weiß, wann es gebraucht werden wird, es ist sich also seiner Umwelt bewusst, wie auch der Schirm ein Bewusstsein für seine Umgebung hat. Natürlich kein Bewusstsein im menschlichen Sinne, aber es entwickelt sich von einem dummen Objekt zu einem, das quasi „mitdenkt“.

Ein kluger Mensch hat mal gesagt: „Jede hinreichend fortgeschrittene Technik ist wie Magie“, und er hat recht. Frodos Schwert ist nicht das einzige Beispiel dafür. Wer sich jetzt dafür interessiert, dem empfehle ich den ganzen Vortrag:

Ein anderer, der mich sehr beeindruckt hat, war Vint Cerf. Er ist der Erfinder des TCP-Protokolls, also einer grundlegenden Technologie, die das Internet erst möglich gemacht hat. Er hat es in den 1970ern entwickelt und gilt daher heute als einer der Väter des Internets. Ich weiß nicht, ob er so glücklich darüber ist. Er fing seiner Rede damit an, dass er sich mit dem berühmten sprechenden Hund verglich. Die Menschen sind so begeistert, dass er sprechen kann, dass niemand sich dafür interessiert, was er eigentlich sagt.

Leider muss ich sagen, dass es mir ganz ähnlich ging, aber vielleicht aus einem etwas anderen Grund. Der Vortrag war durchaus spannend, ich hatte zum Beispiel keine Ahnung, dass die Beschränkung auf den 32Bit-Adressraum in IPv4 seine “Schuld” ist. Bei der Entwicklung des Protokolls 1977 schlug er vor, das ganze erst in einem kleinen Testbetrieb zu untersuchen, um den Adressraum dann im Regelbetrieb auf 128Bit oder mehr zu erhöhen. Der Experiment dauert bis heute an und nennt sich Internet :)

Viel interessanter als das, was er vorgetragen hat, fand ich aber, wie  er es getan hat. Wie er seinen Vortrag mit seinen Händen begleitet hat, das war einfach phänomenal. Die meisten wissen gar nicht, wohin mit den Händen, stecken sie in die Taschen oder fuchteln wild herum. Vint Cerf dagegen ist der Meister der Gesten, im Grunde hätte er auch gut auf den Projektor verzichten können. Es war faszinierend, zu sehen, wie er auch komplexe Zusammenhänge durch Gesten verständlich machen konnte, zum Beispiel das interplanetare Protokoll, dass er im Auftrag der NASA entworfen hat, damit Raumsonden, die den Mars umkreisen beim Datentransfer Rücksicht darauf nehmen, dass die Verbindung instabil ist und Laufzeiten von 20 Minuten und mehr hat. Übrigens ein Protokoll, dass sich die US-Army gekrallt hat, obwohl es noch im Teststadium war (Dejavu anyone ;) ). Jemand aus dem Publikum hat ihn gefragt, woran er als nächstes arbeiten würde, die Antwort war gar nicht so überraschend: an einem intergalaktischen Protokoll, um Daten zwischen Galaxien auszutauschen, wie gesagt, ein faszinierender Mensch.

Nach Chris Hofmanns Vortrag kam er zu uns an den Tisch, um mit Chris zu sprechen. Das wäre die einmalige Gelegenheit gewesen, einer richtigen Internetlegende eine gute Frage zu stellen, aber ich saß daneben, und dachte nur oh mein Gott, das ist Vint Cerf, ich muss ziemlich dämlich ausgesehen haben. Im Nachhinein hätte ich ihm gerne eine Frage gestellt: Was denkt jemand, der so viel zur technische Kommunikation gearbeitet hat, über menschliche Kommunikation.
Vielleicht klappt‘s ja auf der nächsten Konferenz. Auch sein Video ist online:

Außerhalb der eigentlichen Konferenz hatte das Computermuseum Lausanne einige etwas ältere, aber noch voll funktionsfähige Rechner aufgestellt. Ich hatte fast schon Tränen in den Augen, als ich meinen ersten Computer da stehen sah, einen Atari 520ST. Interessant war auch folgendes Bild, es liegen 20 Jahre zwischen diesen beiden Produkten von Apple:
dsc_0369.jpg

Bestraft für Offenheit

Heise berichtet, dass Firefox der fehlerhafteste Browser sein soll und bezieht sich dabei auf diese Studie (oder Auszählung) von Secunia. Eigentlich würde man etwas mehr journalistische Sorgfalt von Heise erwarten, bei Secunia ist klar, dass man auf sich aufmerksam machen möchte, als Sicherheitsdienstleister. Was also stimmt an dieser Studie nicht? Hier werden Äpfel mit Birnen verglichen. Secunia vergleicht die Sicherheitslücken, die die Hersteller gemeldet haben, und bei so einem sinnlosen Vergleich ist Mozilla zwangsläufig im Nachteil. Denn im Gegensatz zu allen anderen Browser-Anbietern, veröffentlicht Mozilla alle gefundenen Sicherheitslücken, unabhängig davon, ob ein Mozilla-Mitarbeiter oder eine externe Person die Lücke gefunden hat. Alle anderen Hersteller, Google, Microsoft, Apple oder Opera veröffentlichen nur solche, die von externer Seite gemeldet wurden, weil ihnen gar nichts anderes übrig bleibt. Selbst gefundene Lücken werden still und heimlich mit einer neuen Version korrigiert.

Miz Firefox kann ich selbst entscheiden, ob ein Update wirklich nötig ist oder ob ich bei einer Vorversion bleibe, weil mich die gefundenen Sicherheitslücken nicht betreffen. Bei den anderen Anbietern bin ich deren Willkür ausgeliefert. Mozilla steht hier also am Pranger, weil es dem Anwender mit größter Offenheit gegenübertritt. Das ist so, als ob eine Stadt, die alle Verkehrsunfälle in ihre Statistik aufnimmt als unsicherer gilt, als eine Stadt, die nur das aufnimmt, was vorher in den Nachrichten war.

Ein Gutes kann man aus der Studie doch ziehen: Obwohl Mozilla wirklich alle gefundenen Sicherheitslücken publik macht, werden hier die Lücken schneller geschlossen als bei allen anderen Anbietern. Übrigens, Mozilla zahlt immer noch 500 Dollar für jede gemeldete Sicherheitslücke anstatt sie zu verschweigen oder auszusitzen, schade, dass sich daran kein anderer Hersteller ein Beispiel nimmt.

Ich weiß jedenfalls, wem ich in Sachen Sicherheit auch in Zukunft vertrauen werde.

Add-on-Entwickler-Treffen in Berlin

Wie schon angekündigt, wird in Kürze das erste Mozilla-Add-on-Entwickler-Treffen in Deutschland stattfinden. Das Programm ist sehr umfangreich und der Eintritt kostenlos.Wer sich für das Mozilla-Projekt interessiert, wird auf jeden Fall auf seine Kosten kommen. Wenn ihr in der Nähe sein solltet oder euch für Add-on-Entwicklung interessiert, lasst euch das nicht entgehen, und sagt es bitte weiter.  Das ist das erste Treffen und ob es noch weitere gibt, hängt natürlich auch von der Resonanz ab.Ich gebe hier die Pressemeldung wieder, mehr Infos gibt es hier.

Mozilla Add-Ons Workshop: Die Community trifft sich in der C-Base-Raumstation

In Zusammenarbeit mit der deutschen XUL-Community lädt Mozilla Insider und solche, die es werden wollen, zum Workshop nach Berlin.

MOUNTAIN VIEW, Kalifornien, Berlin – 4. März 2009: Wer bei Mozilla schon immer einmal einen Blick hinter die Kulissen werfen wollte, sollte sich den 28. März vormerken. Mit Keynotes, Workshops und Präsentationen erfahren Interessierte alles über die Programmierung von Add-Ons, aber auch über neue Mozilla Technologien. Daneben gibt es ausführlich Gelegenheit zur Diskussion mit erfahrenen Entwicklern.

Web-, XUL-, und C++-Entwickler, Blogger, Journalisten – oder einfach nur Neugierige, alle sind auf dem Mozilla Add-Ons-Workshop herzlich willkommen. Die Agenda reicht vom Workshop „mein erstes Add-On“, über „XPCom for Dummies” und Gecko 1.9.1 bis zu Erweiterungen für Firefox Mobile.

Den passenden Rahmen für diese Veranstaltung bietet die C-Base-Raumstation in der Rungestraße 20. Rey Bango, Community Manager für Mozilla Add-ons, und Paul Rouget, Mozilla Tech Evangelist, werden den Mozilla Add-Ons-Workshop begleiten und Keynotes halten, ebenso wie Chris Beard und Brian King.

Weiter Informationen über den Mozilla Add-Ons-Workshop, die komplette Agenda sowie die Möglichkeit zur Online-Registrierung gibt es unter:
https://wiki.mozilla.org/MAOW:2009:Berlin:en