Archiv der Kategorie: Technik

DDoS-Angriff auf MTB-News.de – Post Mortem

Am Abend des 16. Dezember 2014, gegen 19:50 Uhr MEZ wurde die Website bzw. der Server www.mtb-news.de mit einer DDoS-Attacke angegriffen, welche innerhalb kürzester Zeit zu einer Nichterreichbarkeit der Website führte. Im folgenden beschreiben wir den Ablauf des Angriffs sowie unsere ergriffenen Maßnahmen zur Abschwächung und zur zukünftigen Abwehr ähnlicher Attacken.

Was war passiert?

Am 16. Dezember gegen 19:50 Uhr MEZ wurde der Server hinter der Domain www.mtb-news.de mit einer DDoS-Attacke angegriffen. Um 19:51 Uhr meldete unser Monitoring per E-Mail, dass die Website http://www.mtb-news.de/ nicht erreichbar ist. Der erste Reflex bestand daran, die Seite zur Kontrolle im Browser zu öffnen. Da dies nicht funktionierte war der nächste Schritt ein Login per SSH auf dem Server. Auch dies schlug fehl.

Das war einer der Momente, in dem das Rätselraten losgeht. Die erste Vermutung war eine Störung im Rechenzentrum – da aber andere Server im gleichen Rack einwandfrei erreichbar waren, schied diese schnell Möglichkeit aus. Die nächste Möglichkeit war dann ein Hardwareschaden. Ein kaputtes Netzteil hatten wir schon hin und wieder gehabt und dann ist der Server einfach aus und zeigt die selben Symptome.

Rot: Bandbreite die durch den DDoS-Angriff verbraucht wird, Grün: normal verbrauchte Bandbreite (gestapelte Graphen)
Rot: Bandbreite die durch den DDoS-Angriff verbraucht wird, Grün: normal verbrauchte Bandbreite (gestapelte Graphen); am 17. Dezember ab 16 Uhr UTC sieht man, wie der Angriff beendet wurde und der rote Graph auf nahezu 0 fällt.

Bevor ich darüber weiter nachdenken konnte, kam eine Mail vom Hoster, dass wir Opfer einer DDoS-Attacke geworden sind.

Shit!

war meine erste Reaktion, wissend, dass man mit preiswert gemieteten Servern in der Regel einem ordentlichen DDoS-Angriff gegenübersteht wie das Lamm einem Rudel Wölfen.

Der Hoster handelte gemäß seiner eigenen Richtlinien und erdete kurz danach die Route zum betreffenden Server, so dass dieser nicht mehr aus dem Internet erreichbar war.

Erste Schritte

Da nun die Lage klar war, war es jetzt das oberste Ziel MTB-News wieder online zu bekommen. Da der Server fortlaufend und ununterbrochen attackiert wurde, war an eine Reaktivierung der Route zum Server erstmal nicht zu denken.

Es stellte sich nun außerdem noch heraus, dass wir einen klassischen Single Point of Failure in MTB-News.de eingebaut hatten, da eigentlich auch unbetroffene Seiten wie z. B. der Bikemarkt oder das Fotoalbum die auf anderen Servern laufen nur schwer erreichbar waren. Der Grund dafür war, dass die anderen Websites für die Benutzerauthentifizierung auf den abgeschalteten Server zugreifen mussten.

Wir lösten zuerst dieses Problem indem wir den Authentifizierungsdienst auf andere Server installierten und die betroffenen Anwendungen entsprechend umkonfigurierten. Dies funktionierte relativ schnell, so dass wir uns wieder dem eigentichen Problem zuwenden konnten.

Um www.mtb-news.de wieder erreichbar zu machen, kam uns erst die Idee, einen anderen Server als sogenannten Proxy einzusetzen und auf den über das Internet nicht erreichbaren Server über unser internes Netzwerk zuzugreifen. Das hätte vermutlich aber kurze Zeit später dazu geführt, dass auch der Proxy-Server Opfer des Angriffs geworden wäre.

Es musste echte Abhilfe her.

Wir bereiteten nun alles vor, um den DDoS-Traffic durch einen externen Dienstleister weit vor unseren Servern und auch weit vor dem Rechenzentrum ausfiltern zu lassen. Leider erfordert dies einige Maßnahmen, die nicht einfach durch ein “Schalter umlegen” zu machen sind, sondern einige Zeit benötigen.

Lösung des Problems

Das eigentliche Problem ist, dass jeder die IP-Adressen zu beliebigen Diensten im Internet sehr einfach über das DNS-System herausfinden kann. Zum Beispiel hatte www.mtb-news.de die IP-Adresse 85.10.203.55:

[[email protected]:~]
% dig +short www.mtb-news.de
85.10.203.55

Kennt man die IP-Adresse eines Server kann man diese solange mit Internetpaketen bombardieren, bis sie nicht mehr erreichbar ist.

Eine Lösungsmöglichkeit besteht also darin, die IP-Adresse der Server nicht mehr öffentlich im DNS verfügbar zu machen.

Ist die IP-Adresse aber nicht mehr öffentlich einsehbar, kann auch die Website nicht mehr direkt vom Webserver zum Browser ausgeliefert werden, sondern muss über einen sogenannten Proxy-Server weitergeleitet werden.

An dieser Stelle springen jetzt einige Dienstleister ein, die unter Anderem genau solche Proxy-Server als Dienstleistung anbieten. Dazu bieten diese die Möglichkeit seine DNS-Zone (also alle Einträge einer Domain im DNS-System) dort zu hosten. Der Dienstleister kennt dann die wahren IP-Adressen zu den einzelnen Websites, versucht man diese aber selbst aufzulösen erhält man nur IP-Adressen des Dienstleisters gezeigt:

[[email protected]:~]
% dig +short www.mtb-news.de
104.20.13.97
104.20.17.97
104.20.15.97
104.20.14.97
104.20.16.97

Damit haben wir nun die Server aus der direkten Schusslinie geschafft. Ein DDoS-Angriff auf die neuen IP-Adressen wird vom Dienstleister weggefiltert.

Herausgefilterte DDoS-Anfragen, mit Herkunftsländern
Herausgefilterte DDoS-Anfragen, mit Herkunftsländern – nach kurzer Zeit wurden schon knapp 200 Millionen Anfragen an die Webserver verworfen.

Diese Änderungen bedingen eine Aktualisierung der Nameserver-Einträge in der Domain sowie ein Ablaufen der zwischengespeicherten alten DNS-Einträge in den DNS-Resolvern die von unseren Besuchern genutzt werden. Dieser Prozess dauert üblicherweise einige Stunden und so konnten wir www.mtb-news.de erst und endlich am Morgen des 17. Dezember wieder online bringen.

Der zweite Angriff

Wenige Stunden nachdem wir wieder online waren kam nun der nächste Angriff, der erneut dazu führte, dass die Route zum Server vom Hoster genullt wurde. Diesmal war neben www.mtb-news.de auch bikemarkt.mtb-news.de betroffen.

Der Bikemarkt war noch direkt ohne den Umweg über den Proxy-Server erreichbar und dadurch ein einfaches Ziel. Uns blieb nichts anderes übrig, als auch die Bikemarkt-Server mit neuen IP-Adressen zu versehen und ebenfalls mit Proxies zu versehen.

Dass www.mtb-news.de erneut Angriffsziel wurde – obwohl die neuen IP-Adressen ja eigentlich nicht mehr sichtbar sein sollten, lag wohl daran, dass die neue IP-Adresse sich einfach nur im letzten Oktett um eins unterschied (sie lautete 85.10.203.56 statt 85.10.203.55) und sie zudem noch in der alten DNS-Zone gelistet war. Diese Zone war von vielen DNS-Servern noch nicht vergessen worden, so dass es ein leichtes war, die Adresse herauszufinden.

Nach einem Telefonat mit dem Hoster erhielten wir jetzt unkompliziert und innerhalb kürzester Zeit komplett andere Adressen aus ganz anderen Netzen für die betroffenen Server. An dieser Stelle möchten wir (mal wieder) erwähnen, wie schnell und unkompliziert man uns bei Hetzner Online weitergeholfen hat – so wünscht man sich den Service immer. Noch besser wäre es allerdings, wenn Hetzner selbst Filtermaßnahmen gegen DDoS-Angriffe auf ihr Netzwerk implementieren würde und die Kunden im Falle des Falles nicht einfach vom Internet abschaltet. Andere Hoster in ähnlicher Preisklasse machen das mittlerweile auch, z. B. OVH.

traffic
Nach und nach kam normaler Traffic zu den Servern durch und wir konnten wieder Seiten in gewohnter Geschwindigkeit ausliefern :-)

Kurze Zeit später waren alle Dienste wieder erreichbar und die Angriffe kamen danach tatsächlich nicht mehr durch.

Nach 20 Stunden: das Ende

20 Stunden nach Beginn der Angriffe, fast auf die Minute genau, war der Spuk dann endlich vorbei. In der Zwischenzeit wurden pro Sekunde eine fünfstellige Anzahl von Anfragen an die Server weggefiltert. Es prasselten teilweise bis zu 50 Millionen Anfragen pro Stunde auf einen einzelnen Server ein.

Ein derartiger Angriff war für uns auch Premiere – Anfang 2009 hatten wir schon einmal einen DDoS-Angriff, damals auf Rennrad-News.de. Dieser war aber so schnell vorbei wie er angefangen hatte und war schon nach einer Stunde vergessen. Der aktuelle Angriff war da von einem ganz anderen Kaliber – was die verbrauchte Bandbreite wie auch die Dauer betrifft.

Dass wir zufälliges Opfer geworden sind, können wir ausschließen – die zweite Angriffswelle belegt, dass wir gezielt angegriffen wurden. Wer und welche Motivation dahintersteckt ist uns nicht bekannt.

Die Geschichte hat aber durchaus auch gute Seiten gehabt: Erstens haben wir sehr viel dabei gelernt und zweitens werden statische Ressourcen wie Stylesheets, kleine Bilder, Javascript-Dateien usw. jetzt durch ein CDN ausgeliefert, was die Geschwindigkeit mit der unsere Seiten in eurem Browser geladen werden noch mal etwas verbessert hat.

Videos: Unterstützung für verschiedene Framerates

Bisher wurden die hochgeladenen Videos bei der Konvertierung auf 25 Frames pro Sekunde umgerechnet. Das ist seit heute nicht mehr zwingend so, da wir ab sofort verschiedene Framerates unterstützen. Sollte ein Video eine der folgenden Framerates besitzen, so wird diese bei der Konvertierung auch beibehalten:

  • 5 fps
  • 10 fps
  • 12 fps
  • 15 fps
  • 23,976 fps
  • 24 fps
  • 25 fps
  • 29,97 fps

Gerade Videos mit 29,97 fps profitieren davon, da sie jetzt deutlich flüssiger abgespielt werden können.

Alle Videos, die eine nicht aufgeführte Framerate besitzen werden weiterhin auf 25 fps konvertiert.

Hardwareprobleme März 2014 – Post-Mortem

Wir hatten zuletzt ein paar Probleme mit unserer Hardware für Forum und Newsbereich – die Lösung war nicht trivial und wir brauchten auch einige Zeit, bis wir alles wieder im Griff hatten.

Was war passiert?

Wir haben einige Server im Rechenzentrum nicht nur mit einem Netzwerkanschluss zum Internet, sondern jeweils zusätzlich einen Anschluss an ein kleines, privates Netzwerk, in dem sich unsere Maschinen untereinander „unterhalten“ können.

Der Haupt-Datenbankserver für das Forum und den Newsbereich liefert zu Spitzenzeiten Daten mit über 800 Megabit pro Sekunde an die Webserver über unser privates Netzwerk aus. Es häuften sich zuletzt Paketverluste („dropped packets“), die sporadisch, dann aber in sehr großer Zahl auftauchten. Dies führte dann immer wieder dazu, dass ihr zuletzt hin und wieder im Forum Fehlermeldungen zu sehen bekommen habt.

Die erste Vermutung bei Paketverlust ist immer eine schlechte Verkabelung und ich hatte das Ticket ans Rechenzentrum schon fast geschrieben, als ich noch mal die anderen Server im gleichen Netzwerk anschaute. Und siehe da, noch ein Server war davon betroffen. Gleich zwei defekte Kabel auf einmal?

Ich schaute mir die Hardwaredetails der Server dann noch einmal an und fand eine Gemeinsamkeit: die Netzwerkkarte. Beide hatten eine Intel 82574L eingebaut. Eine Recherche im Internet brachte dann die Erkenntnis, dass unsere Server nicht die einzigen sind, die Probleme mit einer Netzwerkkarte diesen Typs haben. Es gab einige Ideen zur Behebung, die aber bei den meisten Leuten und auch bei uns nichts brachten.

Der nächste Schritt war dann das Schreiben eines Tickets ans Rechenzentrum mit der Bitte um Einbau einer neuen Netzwerkkarte.

Ich hatte dann einen Termin am 7. März 2014 um 8:30 für den Einbau der neuen Netzwerkkarte ausgemacht und dieser wurde auch zügig erledigt.

An dieser Stelle möchte ich mal ein kurzes Lob für unseren Hosting-Provider Hetzner Online loswerden: in all den Jahren, die wir jetzt dort sind, gab es noch nie irgendeinen Grund zu meckern – insbesondere der Support macht eine wirklich erstklassige Arbeit. In diesem Preissegment haben wir bisher keinen anderen Hoster mit einer ähnlich hohen Service-Qualität erlebt – und wir kennen mittlerweile durchaus eine Menge preiswerte Hosting-Provider in In- und Ausland.

Ich konfigurierte also die neu eingebaute Netzwerkkarte, lehnte mich entspannt zurück und schaute auf die Monitoring-Programme. Der Maschine sollte ja jetzt schnurren wie ein Kätzchen.

tmux

Denkste! Der Server lief Amok, die Datenbank bekam die Antworten auf ihre Abfragen nicht durch das Netzwerkinterface zum Webserver gesendet und neue Datenbank-Abfragen von den Webservern kamen auch nicht mehr auf dem Datenbankserver an.

Zum Glück hatten die Techniker unserem Wunsch entsprochen, das Kabel der alten Netzwerkkarte noch eingesteckt zu lassen, so dass ich kurzfristig wieder auf die bisherige Konfiguration umschalten konnte.

Jetzt begann das große Rätselraten. Während ich mir die Logfiles und Systemeinstellungen noch mal durchsah, fiel mir auf, dass nun auch noch eine der Festplatten Probleme machte (Auslastung nahe an 100 Prozent) und die Datenbank dadurch stark ausgebremst wurde, was wiederum zu einer langsamen Beantwortung der Abfragen führte. Auch das noch…

Eine kurze Überprüfung mit dem Tool smartctl zeigte, dass die Platte tatsächlich fehlerhaft arbeitete. Also machte ich erneut einen Termin mit dem Support aus – diesmal zum Tausch der Festplatte.

Die Sache mit der Netzwerkkarte legte ich erst mal zur Seite, wichtiger war jetzt die neue Festplatte. Sie wurde auf die Minute genau zum vereinbarten Termin eingebaut und wir konnten den Server kurz danach wieder in Betrieb nehmen. Ich vermute, dass die Pause zum Einbau der Netzwerkkarte – immerhin der erste Power-Cycle nach 15 Monaten Dauerbetrieb – dazu führte, dass die Platte durch die kurzzeitige Temperaturänderung (warm, kalt und wieder warm) versagte. Die neue Platte wurde wieder ins System konfiguriert und das RAID-Rebuild gestartet.

Damit hatte ich jetzt ein Problem weniger – das ursprüngliche war aber nach wie vor ungelöst: die neue Netzwerkkarte war de facto nicht nutzbar.

Also noch mal von vorn. Ich schaute mir jetzt die alles noch einmal in Ruhe an und testete auch den Netzwerk-Durchsatz mit einem synthetischen Benchmark (iperf). Ich stellte fest, dass sie nur einen Bruchteil der erwarteten Geschwindigkeit von 1 Gigabit pro Sekunde erreichte. Dazu kam, dass der Linux-Kernel im Message Buffer Probleme (Absturz des Treibers) mit der neuen Netzwerkkarte anzeigte. Endlich eine Spur!

Es stellte sich relativ schnell heraus, dass der Treiber, den der Linux-Kernel für die Netzwerkkarte lädt, alles andere als ordentlich funktioniert. Die Lösung des Problems war relativ einfach: einen passenden, aktuellen Treiber für die Netzwerkkarte beim Hersteller herunterladen, das Kernel-Modul daraus kompilieren und in den Kernel laden.

Seitdem läuft wieder alles wunderbar, es gibt keine Paketverluste mehr und die Datenbankabfragen werden so schnell beantwortet wie man es erwartet.

EUserv.de – wir haben gerade 227,13 EUR „Lehrgeld“ bezahlt

Einer Kulanz kann nicht entsprochen werden.

Natürlich könnte man kulant sein, wenn man es denn wollte.

Danke EUserv! Die angebotene Leistung konnte uns gegenüber nicht erbracht werden. Die Dienstleistung (Onlinefestplatte) war für uns nicht mal ansatzweise sinnvoll nutzbar und wir haben es daher auch nicht genutzt. Der Support war in unserem Fall langsam und führte nicht zur Lösung des Problems. Antworten gab es teils erst nach mehreren Nachfragen. Nachdem eine Anfrage mehrere Wochen ohne Antwort geblieben war bekam ich auf eine weitere Nachfrage nur einen Punkt als Antwort (s.u.). Das braucht man als Kunde wirklich nicht.

euserv
EUserv.de – so kann man eine Supportanfrage natürlich auch beantworten.

Unsere EUserv Erfahrung: Wir können nur abraten.

29.11.2012: Serverumzug MTB-News.de

Heute Abend gegen 21 Uhr werden wir das Forum und den Newsbereich von MTB-News.de auf neue Server umziehen. Es ist mit einer Auszeit von ca. 2,5 Stunden zu rechnen.

Wir halten euch hier auf dem Laufenden.

20:40 Uhr: Die Vorbereitungen laufen; die DNS TTLs wurden über den Tag verteilt in Stufen herabgesetzt, aktuell stehen sie bei 15 Minuten
21:00 Uhr: Das Forum ist geschlossen, die Datenbank-Dumps laufen.
21:19 Uhr: Die Datenbank-Dumps laufen noch immer. Der größte Brocken ist die Forums-Datenbank, hier sind wir gerade bei knapp der Hälfte angekommen. Sobald der Dump geschafft ist, importieren wir die Datenbanken auf dem neuen Server. Das Importieren dauert immer länger als das Dumpen, da hierbei bestimmte Datenstrukturen aufgebaut werden müssen (Indexe).
21:35 Uhr: Der Seiten des Newsbereichs werden jetzt schon vom neuen Server gerendert, die Auslieferung übernimmt momentan noch der alte Server (als Reverse Proxy)
21:49 Uhr: Der Import der Forums-Datenbank läuft seit einigen Minuten.
22:40 Uhr: Der Import der Forums-Datenbank ist abgeschlossen und wir testen gerade ob alles funktioniert. Bisher sieht es sehr gut aus
22:57 Uhr: Der Umzug des Forums ist fast abgeschlossen, das Forum ist wieder offen.

Post Mortem: Ausfall des Bikemarkts am Morgen des 5. November 2012

Heute morgen in der S-Bahn erreichte mich die Nachricht unseres automatischen Server- und Dienste-Monitorings, dass der Bikemarkt nicht erreichbar ist. Außerdem gab es zum gleichen Zeitpunkt Meldungen über zu hohe Serverlast beim Bikemarkt.

Ich prüfte die Meldungen und stellte fest, dass der Bikemarkt tatsächlich nicht erreichbar war. Ich loggte mich auf dem Webserver per SSH ein (mit Prompt für iOS) und schaute mir die wichtigsten Daten an. Der MySQL-Server kam mit der Bearbeitung von Anfragen aus der Webapplikation nicht hinterher, was dazu führte, dass die Webapplikation in Schockstarre verfiel und sich ebenfalls nicht mehr bewegen wollte.

Mittlerweile vom iPhone auf’s iPad gewechselt, schaute ich mir die laufenden Abfragen im MySQL-Server an (SHOW FULL PROCESSLIST) an und sah erst mal nichts. Es waren zwar eine Menge Abfragen zu sehen, die aber auf dem ersten Blick alle normal aussahen und auch keine schlimmen Locks verursachten usw.

Ich hatte einen wichtigen Termin heute morgen, so dass ich erst mal sehr schlecht gelaunt alles so ließ wie es war.

Gegen 10 Uhr war ich dann – endlich – im Büro und schaute mir die Sache genauer an. Als erste Maßnahme blockierte ich den Zugriff auf den Webserver für alle IP-Adressen außer meiner eigenen. Ziel war es den Fehler möglichst eng einzukreisen anstatt die Nadel im Heuhaufen zu suchen. Was mir dann sofort auffiel: Alle Seiten des Bikemarkts funktionierten nun wie sie sollten, mit Ausnahme der Startseite. Gut. Auf der Startseite passiert nicht viel, es sollte also leicht sein, den Fehler zu finden.

Mir fiel beim erneuten Durchsehen der MySQL-Abfragen auf, dass sich immer wieder ein Muster wiederholte:

SELECTFROMWHERE … ORDER BYLIMIT 16,7216

Der letzte Teil mit dem LIMIT verstörte mich arg, denn er sollte hier nicht auftauchen. Mir schwante Schlimmes…

Und tatsächlich: Ich hatte die Mutter aller Anfängerfehler gemacht. 2012. Nach über 20 Jahren Erfahrung in der Softwareentwicklung.

Gegeben sei ein Schleifenkonstrukt, welches solange durchlaufen, bis eine der angegebenen Abbruchbedingungen erfüllt ist:

<?php
do {
 
    $iterations ++;
 
    // hier geschehen diverse Arbeitsschritte
 
} while ($countCurrent < $countDesired 
    || $iterations >= 5);

Bei jedem Durchlauf der Schleife wird zum Einen der Iterationszähler um eins erhöht und zum anderen ein paar Daten gesammelt. Zum Schluss wird geprüft, ob genügend Daten zusammengekommen sind. Um sicherzustellen, dass diese Schleife nicht zu oft durchlaufen wird (was ja Rechenzeit kostet), dient der Iterationszähler. Sobald er einen bestimmten Wert erreicht hat, wird die Schleife abgebrochen.

Wann beendet sich also diese Schleife?

Wenn genügend Daten zusammengekommen sind oder wenn der Iterationszähler größer oder gleich fünf ist? Nein.

In diesem Fall beendet sich die Schleife, wenn genügend Daten zusammengekommen sind oder Iterationszähler kleiner fünf ist!

Das funktioniert gut, wenn in den ersten vier Durchläufen genügend Daten zusammenkommen. Sobald aber fünf oder mehr Durchläufe benötigt werden, wird diese Schleife niemals beendet. Und genau das ist hier passiert.

Was lernen wir daraus?

  • Ein falscher Vergleichsoperator kann fatale Folgen haben.
  • Die fatalen Folgen treten unter Umständen erst viel später auf (die entsprechende Stelle funktionierte jetzt mehrere Tage problemlos).
  • Die Abbruchbedingungen von „gefährlichen“ Schleifen müssen klarer formuliert werden.

Der schnellste Bugfix wäre in diesem Fall:

<?php
do {
 
    $iterations ++;
 
    // hier geschehen diverse Arbeitsschritte
 
} while ($countCurrent < $countDesired 
    || $iterations < 5);

Verständlicher ist es aber so:

<?php
do {
 
    $iterations ++;
 
    if ($iterations >= 5) {
        break;
    }
 
    // hier geschehen diverse Arbeitsschritte
 
} while ($countCurrent < $countDesired);

23. Juli 2012: Erreichbarkeitsprobleme MTB-News.de und Rennrad-News.de

Am Montag, 23. Juli 2012, kam es tagsüber bei mtb-news.de und rennrad-news.de zu Erreichbarkeitsproblemen bei ca. ein Drittel unserer Benutzer. Der Grund war ein DDoS-Angriff auf die Nameserver unseren DNS-Providers.

Wir hatten das gleiche Problem schon einmal – am 5. Dezember 2006 (damals noch bei einem anderen Anbieter). Damals hatte ich einen Artikel zu den Hintergründen des DNS-Systems geschrieben. Vielleicht ist das ja für den einen oder anderen interessant.

Das Szenario vom 23. Juli glich dem aus dem Jahre 2006 ziemlich, wieder waren fast alle Nameserver und damit auch unsere Websites für viele User nicht erreichbar.

Wir haben gestern Abend die DNS-Auflösung für mtb-news.de und rennrad-news.de in die Hände eines anderen Anbieters gelegt, der hoffentlich gegen diese Art von Angriffen besser geschützt ist.

2011, technisch betrachtet

2011 ist auch – wie in den vergangenen Jahren – wieder eine Menge unter der Haube von MTB-News.de und Rennrad-News.de passiert, auch wenn man viele Dinge optisch nicht oder noch nicht bemerkt.

Ich habe mir für das vergangene Jahr mal ein paar einzelne Projekte herausgesucht, an denen wir gearbeitet haben und werde etwas aus dem Nähkästchen plaudern. Die Liste ist nicht annähernd komplett, sie sollte aber (ohne Gewähr) die wichtigsten Dinge abdecken. 2012 werde ich mir Stichpunkte machen, so dass ich euch dann auch eine komplette Liste geben kann.

Fotoalbum

Eine der auffälligsten Änderungen betrifft die Startseite des Fotoalbums. Dort sind nun an prominenter Stelle immer das „Foto des Tages“ und das „Foto der Woche“ zu sehen. Dabei ist das „Foto des Tages“ erst im Laufe dieses Jahres hinzugekommen. Es werden jeden Tag so viele qualitativ hochwertige Fotos hochgeladen, so dass wir uns entschlossen haben, die Frequenz der „Ehrung“ von guten Fotos etwas gegenüber dem bisherigen Wochentakt zu erhöhen. Zum Foto des Tages wird automatisch dasjenige gewählt, welches am meisten „Likes“ auf sich vereinen kann. Ihr bestimmt also welches das „Foto des Tages“ – und das gleich in zweierlei Hinsicht: Ihr ladet die Fotos hoch und ihr bewertet die Fotos. Das „Foto der Woche“ wird übrigens seitdem immer durch unsere Redaktion ausgewählt.

Die größte sichtbare Änderung betrifft die Foto-Einzelansicht. Wir haben uns vom vorherigen, zweispaltigen Layout verabschiedet und zeigen das Foto nun über die komplette Breite der Seite. Somit kommen die Bilder deutlich besser zu Geltung.

Die visuellen Änderungen sind die, die ihr in eurem Webbrowser direkt mitbekommt. Was „unter der Haube“ passiert, erschließt sich dem Benutzer ja nicht direkt (und es interessiert ja die meisten auch zu recht nicht…). Ich wollte an dieser Stelle noch erwähnen, dass wir im Laufe des Jahres fast die gesamte Codebasis des Fotoalbums nach und nach im laufenden Betrieb ausgetauscht haben. Es kam dabei zu erstaunlich wenig Fehlern, in den meisten Fällen dürftet ihr das nicht mal bemerkt haben. Wir sind mit dem Rewrite des Codes jetzt fast fertig, es fehlen nur noch wenige Teile (z. B. Benutzerliste und Upload-Formular).

Die Seiten des Fotoalbums sind durch den kompletten Rewrite deutlich schneller geworden, was man zum Beispiel sehr gut an der Foto-Einzelansicht sehen kann. Die alte Version benötigte auf auf dem Server knapp 200 Millisekunden zum Erstellen der Seite, nun sind es nur noch rund 50 Millisekunden – das ist immerhin viermal so schnell!

Videobereich

Der Videobereich hat einige Anpassungen im Detail erhalten. Ihr habt ja sicher mitbekommen, dass die Anzahl der Videos – und vor allem der qualitativ hochwertigen Videos – stetig zunimmt. Auch werden mittlerweile fast alle Videos auch als HD-Version angeboten. Das führte dazu, dass wir die Bandbreite für die Videoauslieferung mehrmals erhöhen mussten. Anfangs reichte uns ein Server mit 100 MBit/s zum Ausliefern aus, lediglich zu Spitzenzeiten gab es vereinzelt Probleme mit zu langsamen Streaming. Wir stellten uns dann einen zweiten Server dazu, mit welchem wir die Bandbreite verdoppeln konnten. Seit der Eurobike haben wir dann die Geschwindigkeit von 200 MBit/s auf 1,1 Gbit/s erhöht.

Winterpokal

Die größte Änderung im Winterpokal ist die 2011 neu hinzugekomme Möglichkeit, auf viele Funktionen über ein sogenanntes API zuzugreifen.

Damit ist es möglich, den Winterpokal in andere Websites zu integrieren oder auch Apps für iPhone und Co. zu bauen. Es sind einige Projekte dazu in Arbeit – ich denke zur Saison 2012/2013 wird da einiges in den AppStores zu finden sein.

Wer sich für die Details interessiert, kann sich die API-Dokumentation auf GitHub anschauen. Dort gibt es eine Referenz aller Funktionen und ausführliche Beispiele.

Wir arbeiten daran, die APIs auch für die anderen Anwendungen einzubauen.

MTB-News.de – News

Am 19. Januar ist der neue News-Bereich gestartet. Vorher haben wir eine Art Plugin für die Forensoftware „vBulletin“ genutzt, welche die Themen eines bestimmten Forums etwas anders als sonst angezeigt hat. Die News-Artikel waren Anreißertexte, welche meist ein Bild enthielten und verwiesen auf jeweils ein Thema im Forum, welches dort auch ganz normal diskutiert werden konnte.

Mit dem Ausbau des News-Bereiches war schon seit längerer Zeit klar, dass die bisherige Lösung unseren Ansprüchen nicht gerecht wird, in vielerlei Hinsicht nicht skaliert und keinerlei Anpassungsmöglichkeiten bot. Wir haben uns 2010 lange Gedanken gemacht, wie ein Relaunch der News technisch und optisch aussehen könnte. Die erste Idee war, die Software einfach selbst zu schreiben. Die Integration ins Forum wäre damit sehr einfach gewesen, die nötigen Schnittstellen zur Benutzerauthentifizierung usw. haben wir über die Jahre schon gebaut. Der Aufwand, das Content Management System (CMS) zu bauen ist aber kein trivialer und so kam Thomas irgendwann auf die Idee, einfach ein bekanntes (das bekannteste?) CMS zu nutzen und um Schnittstellen zu erweitern.

Also begannen wir, den Newsbereich mit WordPress umzusetzen.

Im Großen und Ganzen gab es drei Probleme zu lösen:

  1. Importieren aller alten News-Artikel
  2. Übernahme neuer Artikel ins Forum – die Diskussionen sollten wie gehabt dort stattfinden
  3. Kommentarfunktion im WordPress, mit der man direkt auf das Thema im Forum antworten kann

Import vorhandener Artikel

Die Forumsoftware und WordPress speichern Beiträge auf komplett verschiedene Art und Weise. Wir mussten also einen Konverter bauen, der die News-Beiträge aus dem Forum ausliest und diese im WordPress speichert, denn die Artikel sollten ja komplett über den neuen Newsbereich abrufbar sein.

Ich habe dazu einfach eine kleine Applikation in PHP geschrieben, die alle Themen aus dem Newsforum einliest und von jedem ersten Beitrag eines Themas (das ist ja der News-Artikel) einen Eintrag in der WordPress-Datenbank erzeugt. An sich kein großes Problem, würden die Beiträge im Forum bereits als HTML vorliegen. Tun sie leider nicht.

Im Forum werden Formatierungen am Text mit BBCode vorgenommen. WordPress speichert aber alles als HTML. Die Versuche, den BBCode-Parser von vBulletin in unserem Konverter zu benutzen, schlugen allesamt fehl, es tauchten an allen Ecken und Enden Probleme auf. Die Art und Weise, wie vBulletin aufgebaut ist, macht das Weiterverwenden einzelner Teile extrem schwer bis unmöglich.

Ich habe dann einfach „Trick 17“ angewendet: Ich habe mir die Seite der Themenansicht per HTTP geladen, einen DOM-Baum daraus erzeugt und das fertig gerenderte HTML des News-Artikels direkt aus dem DOM extrahiert.

Das Mappen der Benutzer-IDs und das Erstellen eines Datenbankeintrags im WordPress war dann trivial.

Übernahme neuer Artikel ins Forum

Wenn ein neuer Artikel in den News veröffentlicht wird, soll dieser automatisch ein neues Thema im Forum starten und der Artikelinhalt soll wie bisher auch im ersten Beitrag des Themas stehen.

Ich habe die selbe Applikation mit der wir die Forenbeiträge ins WordPress übernommen haben um die umgekehrte Funktionalität erweitert.

Auch hier passiert kein Voodoo, die Schwierigkeiten waren aber ziemlich ähnlich: Aus dem HTML, mit dem die Texte in WordPress strukturiert sind, galt es BBCode zu machen, so dass das Forum die Artikel halbwegs korrekt anzeigen kann.

Das Wort „halbwegs“ habe ich deshalb geschrieben, da mit BBCode nur eine Teilmenge der Möglichkeiten zur Textstrukturierung zur Verfügung steht. Bestimmte Dinge können also nicht vom WordPress ins Forum übernommen werden.

Wie konvertiert man nun HTML nach BBCode? Ich habe eine Weile überlegt, bis mir XML und XSL einfielen. Wenn man die Artikel in XHTML schreibt hat man ein syntaktisch korrektes XML-Dokument vorliegen. Und mit XSL kann man aus einem XML-Dokument so ziemlich alles bauen, was sich mit Bits darstellen lässt. Also auch BBCode.

Ich habe mir also ein simples XSL-Stylesheet gebaut, welches bestimmte Auszeichnungen des XHTML-Dokumentes in die BBCode-Entsprechungen konvertiert:

Einfacher geht’s kaum!

Das Mappen der Benutzer-IDs von WordPress nach vBulletin und das Erstellen von Beitrag und Thema im Forum war danach ähnlich trivial wie der umgekehrte Weg.

Jedes Mal wenn ein Artikel im WordPress veröffentlicht wird (oder ein bereits veröffentlichter Artikel verändert wird), erzeugen oder aktualisieren wir das entsprechende Thema im Forum.

Kommentarfunktion

WordPress bietet eine eigene Kommentarfunktion, die aber entweder anonym ist oder aber einen Account im WordPress erfordert. Beides war nicht zufriedenstellend – wir wollten, dass unsere Benutzer Beiträge direkt mit ihrem Foren-Account kommentieren können.

Wir haben dann einfach das Kommentarfeld umgebaut, so dass es direkt ans Forum abgesendet wird und nicht ans WordPress.

Hier passiert also keine Magie.

Die Anzeige der Kommentare lassen wir direkt vom vBulletin rendern und binden sie nur noch an die entsprechende Stelle im WordPress ein. Das hat den Vorteil, dass sich vBulletin schon um Behandlung von gelöschten oder nicht freigeschalteten Beiträgen kümmert.

Rennrad-News.de – Forum

Die Änderung mit dem größten Impact auf Benutzerseite ist wohl der Wechsel der Forensoftware bei Rennrad-News.de gewesen. Vergleichbar sicher mit einer Herztransplantation.

Die bisher bei Rennrad-News.de verwendete Forensoftware vBulletin ist im Kern über zehn Jahre alt und das spürt man auch an allen Ecken und Enden. Moderne Software wird einfach anders gebaut und bringt auch nicht mehr die Nachteile von Brocken wie vBulletin mit, was Übersichtlichkeit, Wartbarkeit und auch Performance angeht.

Wir haben uns nach längeren Tests dazu entschieden, ab sofort XenForo als Herzstück von Rennrad-News.de einzusetzen. Die Übernahme der Daten von vBulletin klappte fast ausnahmslos (die Interessengemeinschaften werden wir nachliefern, sobald XenForo Unterstützung dafür bietet), wir mussten das Forum am Tage des Software-Wechsels nur knapp acht Stunden offline nehmen. Es wäre sogar noch schneller gegangen, wenn nicht noch ein Fehler in einem selbst geschriebenen Modul aufgetreten wäre.

Ein für uns sehr wichtiger Punkt ist das Thema Single Sign-On – mit dem Einloggen ins Forum stehen alle Dienste von Rennrad-News.de (oder MTB-News.de) zur Verfügung, ohne dass man sich noch mal gesondert einloggen müsste. Da wir unsere Dienste auf verschiedene Server an verschiedenen Standorten hosten, brauchten wir eine robuste Möglichkeit, Benutzer von jedem beliebigen Server gegen die Benutzerdatenbank des Forums zu authentifizieren. Wir haben uns für die vBulletin-Installationen eine eigene Web-Applikation gebaut, welche ein HTTPS-API zur Authentifizierung von Benutzern zur Verfügung stellt.

Mit XenForo ist das alles einfacher geworden – wir brauchen die gesonderte Web-Applikation nicht mehr, da es sehr einfach ist, solche Funktionalitäten direkt als XenForo-Modul zu implementieren.

Technisch gesehen war der Umstieg ein riesiger Fortschritt und auch auf Benutzerseite gibt es viele neue Funktionen und Vereinfachungen. Wir planen, MTB-News.de auch auf XenForo zu migrieren, hierfür müssen aber noch viele Abhängigkeiten aufgelöst werden, so dass ihr sicher noch ein klein bisschen mit der aktuellen Forensoftware vorlieb nehmen müsst.

Rennrad-News.de – einheitlicher Seitenkopf

Zeitgleich mit der Umstellung der Forensoftware haben wir auf Rennrad-News.de einen einheitlichen Header eingebaut. Dieser wird jetzt auf allen Seiten benutzt und ermöglicht eine einfach Navigation durch die verschiedenen Bereiche.

Um nicht jede Anwendung einzeln anfassen zu müssen wenn sich mal ein Link im Header ändert oder ein neuer Link hinzukommt, habe ich mir ein System überlegt, mit dem ich den Header gleichzeitig in allen Anwendungen aktualisieren kann. Die technische Umsetzung erkläre ich mal in einem anderen Artikel – es lässt sich wohl am besten mit „die simplen Ideen sind meist die besten“ zusammenfassen.

Keine Frage, dass ein einheitlicher Seitenkopf auch bei MTB-News.de eingeführt wird. Wir arbeiten bereits daran!

Fazit

Es ist wieder eine Menge passiert – vieles sichtbar, vieles aber auch „unter der Haube“. Und 2012 wird noch mehr passieren, die ToDo-Listen und das Ticketsystem sind voll bis Anschlag :)

Ich freue mich auf 2012!

Rennrad-News.de – Serverumzug, mal wieder…

Es ist mal wieder an der Zeit – Teile von Rennrad-News.de ziehen heute Abend (25. November 2011) auf neue Hardware um.

Wir versuchen die Downtime so kurz wie möglich zu halten und werden die wichtigsten Dienste (Forum und wichtige interne APIs) als Erstes umziehen. Wir schätzen, dass das Forum nach ca. einer Stunde wieder online gehen kann.

An dieser Stelle bekommt ihr laufend Updates zum aktuellen Stand des Serverumzugs. Ihr könnt auch unserem Twitter-Account @rennradnews folgen, dort wollen wir auch Updates zum Fortschritt posten.

19:45 Uhr T-15 Minuten, Vorbereitungen laufen.
19:59 Uhr T-1 Minute, wir deaktivieren gleich das Forum.
20:00 Uhr T+0 Minute, das Forum ist deaktiviert. Wir beginnen jetzt mit dem Transfer der Datenbank (dem Herzstück des Forums)
20:22 Uhr T+22 Minuten, der Datenbank-Dump ist auf dem neuen Server angekommen und wird gerade importiert. Es handelt sich um etliche Gigabytes Daten.
20:33 Uhr T+33 Minuten, die Datenbank ist importiert und alle Dateien wurden übertragen – wir testen noch ein wenig und sind gleich wieder online!
20:40 Uhr T+40 Minuten, wir haben die DNS-Records auf den neuen Server umgebogen und sind mit jetzt schon wieder über 40 Leuten online!

Rennrad-News.de wegen Systemupdates kurz offline

Wir spielen momentan (24. Januar 2010, seit ~10:30 Uhr) einige Systemupdates in die Server von Rennrad-News.de ein. Daher ist Rennrad-News.de momentan nicht erreichbar.

Wir hoffen, gegen 13 Uhr wieder da zu sein.

Entschuldigt bitte die Umstände.

BTW, wir haben auch einen Twitter-Account: @rennradnews

Update, 12:55 Uhr: Wir werden es nicht schaffen, um 13 Uhr wieder online zu sein. Der letzte Server hängt noch im Filesystemcheck und ist der Meinung, dass er gern noch etwas Zeit dafür hätte :-(

Update 13:55 Uhr: Alles wieder ok :-)