Kategorie: Allgemeines (Seite 11 von 21)

Am 17.9.2014 kam es bedauerlicherweise zu einem schweren Crash des MySQL-Servers für kostenlose Benutzer. Premium-Benutzer waren nicht betroffen. In diesem Blogpost wird werden wir die Ursache und den Umfangs des Schadens beleuchten. Betroffene Benutzer, die Daten verloren haben oder deren Tabellen beschädigt wurden melden sich bitte per Support-Ticket (in der Verwaltung) unter Angabe des Datenbank-Namens. Wir erstellen gerade eine Liste aller noch betroffenen Tabellen und melden uns bei den betroffenen Benutzern per Ticket.

Zeitlicher Verlauf

Am 17.9. gegen 16:25 wurde der Datenbank-Server für angekündigte Wartungsarbeiten heruntergefahren. Die defekte Hardware wurde getauscht, getestet und um 16:48 wurde der Datenbank-Server wieder gestartet. Der MySQL-Server wurde gestartet, hat aber den Timeout des Prozess-Managers für den Start überschritten und wurde als „nicht gestartet“ markiert, woraufhin ein erneuter Versuch unternommen wurde. Der zweite MySQL-Prozess versuchte, auf die Daten-Dateien der InnoDB-Storage-Engine zuzugreifen, die von dem anderen Prozess erwartungsgemäß gesperrt waren. Dabei scheint eine Race Condition aufgetreten zu sein, die im zweiten Prozess den Crash-Recovery-Vorgang von InnoDB gestartet hat. Der Versuch, die Crash-Recovery-Daten auf den gesperrten Tablespace anzuwenden hat den Tablespace irreparabel beschädigt. Nachdem beide Prozesse von einem Administrator gestoppt waren war der Schaden bereits angerichtet.

Der MySQL-Prozess ließ sich anschließend nicht mehr starten, da der defekte Tablespace einen Bug in MySQL ausgelöst hat (so sieht das aus). Der Versuch, den Tablespace um die defekten Datenbanken zu bereinigen und sofort zum Laufen zu bekommen schlug fehl, so dass wir eine Liste aller Datenbanken erstellen mussten, die InnoDB-Tabellen enthielten. Dieser Vorgang dauerte bis ca. 20:00. Diese Datenbanken haben wir anschließend mittels mysqldump exportiert, während InnoDB im „forced recovery“-Modus lief. Gegen 1:00 war dieser Vorgang abgeschlossen, 41 Datenbanken ließen sich nicht mehr exportieren. Anschließend haben wir einen neuen InnoDB-Tablespace erstellt, den MySQL-Server mit dem neuen Tablespace (und damit ohne die InnoDB-Tabellen) gestartet und den Import der exportierten Datenbanken gestartet. Der Import wurde am Morgen des 18.9. abgeschlossen.

Schadensumfang

Bei der Prüfung, wie viele und welche InnoDB-Tabellen existierten stellte sich heraus, dass eine mittlere vierstelle Anzahl von Datenbanken InnoDB-Tabellen enthielten. Davon konnten wir gut 90% der Datenbanken ohne Probleme wiederherstellen. Bei den verbleibenden Datenbanken fehlen Daten der letzten Tage, da diese beim Anwenden des Recovery-Logs durch MySQL verloren gingen. In etwa 0,2% der Fälle sind Tabellen vollständig verloren gegangen.
Für so gut wie alle beschädigten Datenbanken existierte ein Backup.

Konsequenzen

Eine wichtige Sache haben wir gelernt: niemals, NIEMALS darf ein MySQL-Prozess doppelt laufen. Damit das nicht noch einmal passiert startet der Datenbank-Server die MySQL-Prozesse nicht mehr automatisch, sondern ein Administrator muss den Prozess starten. Die Ursache für das Problem ist damit unterbunden.
Wir öffnen bei jedem Benutzer, der noch betroffen ist, ein Ticket um zu erfahren, ob der rückgesicherte Stand in Ordnung ist oder noch etwas zu tun ist.
Wir entschuldigen und für die Unannehmlichkeiten und bedanken uns für die vielen aufmunternden Worte 🙂

Bei lima-city können für jeden Account neben der Subdomain benutzername.lima-city.de mehrere Subdomains à la benutzername.lima-city.at und .ch, benutzername.12hp.de, .at, .ch und viele mehr angelegt werden.

Heute haben wir sechs neue Domains hinzugefügt, davon 3 nTLDs:

lima-city.rocks
webspace.rocks
lima.zone
2ix.de
2ix.at
2ix.ch

Insgesamt gibt es damit 15 Möglichkeiten, unter welcher Subdomain die Homepage erreichbar sein kann.Die komplette Liste gibt es in der Hilfe unter „Welche Subdomains stellt lima-city kostenlos zur Verfügung?„.

Für detaillierte Informationen zu aktuellen Statusmeldungen rund um die lima-city-Infrastruktur haben wir einen Twitter-Account angelegt: @lima_status

Wir werden dort Neuigkeiten zu aktuellen Störungen, Problemen und Wartungsarbeiten posten. Eine Integration auf lima-status.de ist ebenfalls in Arbeit.

Heute möchte ich über ein Feature berichten, das bereits seit Oktober 2013 bei lima-city im Hintergrund aktiv ist und unbemerkt für mehr Sicherheit sorgt: unser Spam-Schutz. Und zwar nicht für E-Mail, sondern für die Webseiten.

Im Oktober 2013 wurde es uns langsam zu viel: wir investierten einen großen Teil unserer täglichen Arbeit darin, Spam oder deren Auswirkungen aufzuräumen. „Spam“ allerdings nicht im klassichen Sinne von E-Mails sondern in der Web-Version:

• Kommentar-Spam bei WordPress-Blogs
• Bot-Registrierungen und Spam-Posts bei Foren
• Automatisierte Bot-Logins in Blogs und CMS
• Ausnutzung von fehlerhaft programmierten Kontaktformularen für „normalen“ Spam-Versand

Die Auswirkungen davon sind recht vielseitig. Zum einen kostet es uns Rechenkapazität, diese ganzen sinnlosen Anfragen zu verarbeiten. Es werden aber auch, z.B. bei den Bot-Registrierungen, Bestätigungs-E-Mails versendet. Diese wiederum werden zum Teil als „Mailbomben“ verwendet. Benutzeraccounts wurden kompromittiert und Webseiten gekapert. WordPress-Admins haben viel mit dem Aussortieren von Spam-Kommentaren zu tun. Datenbanken werden von Spam-Registrierungen über Jahre hinweg mit hunderttausenden, sinnlosen Bot-Accounts zugemüllt. All das wollten wir abschaffen.

Wir hätten verschiedene Wege gehen können. Es wäre möglich gewesen, alle Webmaster anzuschreiben und Fehler zu beheben. Das wäre aber eine niemals endende Mammutaufgabe geworden. Wir haben uns dafür entschieden die Verursacher zu verbannen. Inzwischen setzen wir dazu ein zweistufiges System ein:

Stufe 1: Einsatz der Blocklist (Okt 2013)

Im Oktober 2013 haben wir die erste Stufe unseres Spam-Schutz installiert. Über blocklist.de bekommen wir alle 30 Minuten eine aktualisierte Liste von IP-Adressen, die als Bots bekannt sind. Diese Bots schließen wir von unserem Angebot aus, der Grund für die Sperre und ein Link zum Delisting bei blocklist.de wird angezeigt.

Daneben wird auch unsere Support-E-Mail-Adresse angezeigt, damit sich Besucher mit Problemen bei uns melden können.

Diese Sperre blockiert täglich zwischen 45.000 und 80.000 Zugriffe.

Stufe 2: Einsatz verhaltensbasierter Filter (März 2014)

Die Sperre über Blocklist war zwar effektiv, half aber nur gegen bereits bekannte Bots. Wenn ein Bot nicht gemeldet war gab es keinen Schutz. Im März 2014 haben wir daher einen weiteren Filter hinzugefügt, der das Browser-Verhalten testet. Es werden einmalig mehrere Eigenschaften des Browsers getestet und in Cookies abgelegt (diese tauchen als _lcp-Cookies auf, es gibt keine statistische Erfassung der Besucher!). Wenn der Besucher bestimmte Aktionen durchführen will (z.B. einen WordPress-Kommentar, eine Registrierung in einem Forum, etc) werden die Eigenschaften abgefragt. Weist ein Besucher bestimmte Browsermerkmale nicht auf handelt es sich um einen Bot, der nur vorgibt dieser Browser (z.B. ein Firefox Version 26 oder Chrome) zu sein. Diese Zugriffe werden dann geblockt.

Dieses Vorgehen ist sehr zielgerichtet und äußerst effektiv. Es blockt täglich zwischen 8.000 und 20.000 Aktionen (nicht Zugriffe) die nicht erwünscht sind. Selbstverständlich wird auch hier unsere Support-E-Mail-Adresse angezeigt.

Das gesamte System blockiert so bis zu 100.000 Zugriffe am Tag, die für uns und den Webseitenbetreiber keinen Nutzen sondern nur Arbeit erzeugen. In einer demnächst kommenden Statistik werden diese Zugriffe dann auch gekennzeichnet. Wir haben seit der Umsetzung unserer Lösung so gut wie keinen nennenswerten Spam mehr gesehen. Wenn doch etwas auftauchen sollte: bitte gebt uns Bescheid, damit wir unsere Filter ggf. anpassen können!

Kurznachricht: Der Filemanager, unser Web-FTP, ist nun auch über HTTPS erreichbar: https://filemanager.lima-city.de/

Jeder hasst Server-Ausfälle. Du hasst sie, und wir auch. Aber sie passieren. So auch heute, am 25.6.2014 für 6 Stunden und 30 Minuten. Und da wir an unserer Transparenz arbeiten, will ich erklären, was passiert ist und warum die Behebung so lange gedauert hat.

In diesem Blog-Post werde ich erklären:

1. wie das ganze zustande gekommen ist,
2. was wir daraus gelernt haben und was wir tun, damit das nicht noch einmal passiert und
3. was man bei lima-city für’s Geld bekommt und was wir in dem Bereich aktuell planen (und wir brauchen Deinen Input dafür!).

Die Ursache

Heute morgen um 6:56 fing alles an. Auf einem unserer Server, der als System für verschiedene VMs dient, ging der RAM zur Neige. 128GB stecken in dem Server, aber gereicht hat es nicht. Der Host sendete 20 Sekunden lang  Nachrichten an zwei VMs, dass sie sich bitte beenden sollen, sonst würde er das für sie tun. Genau das hat er dann auch getan, und zwar bei dem größten Bad Boy: dem Webspace. Um 6:57 wurde diese VM vom Host-System beendet. Ein bisher einmaliges Ereignis, das auch nicht vorauszusehen war.

Damit war erstmal Feierabend mit dem Webhosting. Ab diesem Moment liefen dann auch die Monitoring-Systeme an und verschickten munter Alarm-E-Mails. Leider war aber zu diesem Zeitpunkt kein Techniker anwesend, um diese zu lesen und zu handeln, aber es sollte noch schlimmer werden: Selbst als die ersten Admins gegen 7:00 erreichbar waren, stellten diese fest, dass es für diesen Fehlerfall gar keine Dokumentation gab. So blieb nichts anders übrig, als die Situation zu analysieren und zu warten, bis derjenige erreichbar ist, der weiß, was zu tun ist (Spoiler: das wäre dann ich). Ich aber hatte bis 4:00 am Server Wartungsarbeiten durchgeführt (die im Übrigen nichts mit dem Ausfall zu tun hatten) und habe Schlaf nachgeholt. Und als ich dann gegen 13:00 auf mein bis dahin lautlos gestelltes Handy guckte, war der Puls bei 180: Monitoring-Mails bis zum Ende seit 7:00 morgens. Das nenne ich mit dem falschen Fuß aufstehen.

Die Systeme wurden dann ganz schnell wieder gestartet und liefen gegen 13:31 wieder. Zwischen 14:49 und 14:52 haben wir noch eine Datenbank  neu synchronisiert. Die Webspaces zeigten in der Zeit den „Schluckauf“-Fehler.

Die Konsequenz

Was tun wir also, damit a) genau dieses Problem und b) ähnliche Probleme nicht wieder auftreten?

1. die RAM-Limits wurden angepasst, so dass die maximale Ausnutzung immer noch genügend freien RAM lässt
2. wir werden unsere Notfall-Dokumentation überarbeiten
3. wir suchen oder bauen Software-Tools, mit denen wir technischen Abläufe automatisieren können, sprich: Technisches Wissen in ausführbare Software umsetzen, die im Notfall nur ausgeführt werden muss

lima-city Webspace: was bekommt man für sein Geld?

Da nun auch die Aussage aufgetaucht ist „Bekomme ich etwas erstattet? Ich hab ja bezahlt, wie kann sowas angehen!“ möchte ich noch etwas erklären zum lima-city Webspace: Wir sind ein Anbieter von kostenlosem Webspace. Wir verkaufen zusätzlich Domains. Man sieht bereits: wir verkaufen Domains, wir verkaufen keinen Webspace. Wir geben für den Webspace auch keine Verfügbarkeitsgarantie. Wir stecken zwar viel Einsatz und Herzblut in die Qualität des Webspace, aber es ist eben auch nur begrenzt Geld und Arbeitszeit dafür vorhanden.

Die Frage deutet bereits darauf hin, dass viele Benutzer hier kritische Anwendungen laufen lassen und sich auch eine garantierte Verfügbarkeit wünschen. Die kann man allerdings auch nur für Geld bereitstellen. Und weil ich gerne bereit bin, Features einzuführen die gebraucht werden (und natürlich auch Geld bringen ;-)) habe ich eine Umfrage erstellt, damit wir herausfinden können, wie so ein Premium-Upgrade denn aussehen soll (und was es kosten darf!):

Umfrage zum Premium-Paket

Es wäre schön, wenn auch die User, die  kein solches Premium-Paket haben wollen, dort teilnehmen. Nur dann wissen wir, wie groß der Anteil der User ist, die das Premium-Paket haben wollen.

Ich könnte mir vorstellen, dass wir das Ganze auf die Beine stellen, wenn etwa 50 User zusammenkommen.

Ich freue mich auch auf viele konstruktive Kommentare. Und wenn jemand seinem Ärger freien Lauf lassen möchte: phillipp.roell (ät) trafficplex.de ist meine E-Mail-Adresse.

Die Hoster der Funpic.de AG Funpic und Ohost sind scheinbar dauerhaft offline. Die Vorstände der Funpic.de AG haben ihr Amt niedergelegt und es sind keine Webseiten mehr erreichbar. Wir berichten über die Situation, Neugkeiten und Hintergründe unter funpic-offline.de.

Für die bei lima-city gehosteten Domains haben wir bisher 2 DNS-Records gehabt, die die den E-Mail-Service referenziert haben: einen MX-Record der auf mail.domain.tld zeigt und einen A-Record mail.domain.tld.

Das wurde nun geändert, so dass nur noch ein Record erstellt wird: ein MX-Record, der auf mail.lima-city.de zeigt. Das hat zwei Gründe:

1. Das TLS-Zertifikat für SMTP-Mail ist für mail.lima-city.de ausgestellt. Ein Server, der über TLS (=SSL) mit mail.domain.tld verbinden würde bekäme eine Zertifikatswarnung, da sich die Hostnamen unterscheiden. Das ist nun nicht mehr der Fall, da mit mail.lima-city.de verbunden wird.
2. Da nur ein A-Record angelegt war gab es auch keine IPv6-Konnektivität. mail.lima-city.de ist aber auch via IPv6 erreichbar. Ein weiterer Schritt also zur vollen IPv6-Konnektivität 🙂

Für bestehende Domains wurde der MX-Record auch geändert, allerdings nur, sofern keine manuellen Änderungen am MX-Record UND an dem A-Record mail.domain.tld vorgenommen wurde. Der Record mail.domain.tld wurde für keine Domain gelöscht, da er für SMTP/IMAP/POP3 verwendet werden könnte.

Auf vielfachen Wunsch hin sind jetzt bei allen gekauften Domains die DNS Einträge direkt editierbar. Es ist nicht mehr nötig das A-Record Feature zu erwerben.

Diese Änderung betrifft sowohl neu gekaufte als auch bereits vorhanden Domains.

Den Editor findet man, wenn man in der bei einer gekauften Domain auf Details und dann Nameserver-Einträge ändern klickt.

Da wir immer wieder kleine und große Verbesserungen vornehmen haben wir nun mal wieder etwas größeres geändert: die Links sind nun nicht mehr standardmäßig unterstrichen sondern nur noch bei einem Hover – gleichzeitig ist die Farbe blau statt wie vorher grau.

Damit folgen wir vielen großen Webseiten: Wikipedia, Amazon, Youtube, heise, Yahoo, Twitter und vielen mehr, die ebenfalls auf diese Art der Typographie setzen.

Daneben haben wir noch ein paar Änderungen an ein paar Kontrast-Einstellungen vorgenommen die nicht wirklich auffallen sollten aber die Lesbarkeit erhöhen.