Nachdem die kostenlosen Subdomains unter *.lima-city.de schon seit einiger Zeit ein gültiges SSL-Zertifikat haben, haben wir nun auch alle weiteren Domains für kostenlose Subdomains nachgezogen. Bei folgenden kostenlosen Subdomains ist nun SSL aktiviert:

benutzername.lima-city.de
benutzername.4lima.de
benutzername.12hp.de
benutzername.2ix.de
benutzername.lima-city.at
benutzername.4lima.at
benutzername.12hp.at
benutzername.2ix.at
benutzername.lima-city.ch
benutzername.4lima.ch
benutzername.12hp.ch
benutzername.2ix.ch
benutzername.webspace.rocks
benutzername.lima-city.rocks
benutzername.lima.zone

Damit haben nun sämtliche derzeit angebotenen kostenlosen Subdomains ein gültiges SSL-Zertifikat. Vorher war das nur unter benutzername.lima-city.de der Fall: Zum Beitrag „SSL für (fast) alle!“.

Um eine automatische Weiterleitung von HTTP auf HTTPS zu aktivieren ist auch keine .htaccess-Datei mehr nötig. Klicke einfach in der Verwaltung unter „Websites & Domains“ bei der jeweiligen Subdomain auf „bearbeiten“ und aktiviere den Haken bei „SSL erzwingen“. Nach dem Speichern kann es noch ein paar Minuten dauern, dann ist die Änderung aktiv und Besucher werden automatisch von HTTP auf HTTPS umgeleitet.

Nach dem PHP-Upgrade im September steht nun eine weitere Änderung unserer Infrastruktur an. Vor kurzem haben wir die in der Verwaltung bei FTP- und MySQL-Zugangsdaten angezeigten Servernamen geändert. Anstatt dort ftp.lima-city.de und mysql.lima-city.de bzw. servername.lima-premium.de anzuzeigen steht dort nun einheitlich benutzername.lima-ftp.de und benutzername.lima-db.de.

Das hat damit zu tun, dass wir unserer bisherige Architektur ersetzen. Bisher haben wir für MySQL-Datenbanken und Freespace einen einzelnen, sehr gut ausgestatten, Server verwendet. Aus diversen Gründen möchten wir von diesem monolithischen Modell zu einem horizontal geteilten Modell, bei dem wir mehrere „kleinere“ Server verwenden, auf dem dann jeweils weniger Benutzer liegen.

Dieses Modell haben wir beim Premium-Paket schon seit Beginn im Einsatz. Dort hatten wir die Möglichkeiten, die Erkenntnisse aus unserer langjährigen Erfahrung mit dem Webspace am Reißbrett für ein neues System einzusetzen. Da wir sehr gute Erfahrungen mit der Architektur des Premium-Pakets gemacht haben werden wir diese Architektur nun auch auf den kostenlosen Webspace übertragen.

Das hat für uns, neben der besseren Skalierbarkeit, auch den schönen Vorteil dass sich das technische Setup für uns deutlich vereinfacht. Auch hier können wir unsere Erfahrungen aus der Neukonzeption des Premium-Paketes nutzen. Dort haben wir uns entschieden, alle Dienste (den Apache-Webserver, FTP-Server und MySQL-Server, daneben noch ein interne Management-Services für Anlegen und Löschen von Dateien, Backup-Erstellung, Löschen von Webspaces von gelöschten Benutzern etc.) ganz neu zu „verpacken“ und haben uns für die Container-Lösung Docker entschieden. Obwohl Docker damals noch in den Kinderschuhen steckte hat sich diese Entscheidung bewährt. Seitdem erstellen wir ein Container-Image pro Dienst das wir automatisiert auf alle Server ausrollen können. Zudem haben wir die Möglichkeit, „rollende Updates“ auszuführen und Updates notfalls in wenigen Sekunden rückgängig zu machen. Bisher mussten wir den Freespace noch als Sonderlösung pflegen, das ist nun vorbei.

Was ändert sich für mich? Wir werden demnächst beginnen die ersten Benutzer umzuziehen. Der Umzug geht mit einer kurzen Abschaltung des Webspace von wenigen Minuten einher. Jeder Benutzer erhält nach dem Umzug eine E-Mail mit den neuen Hostnamen von FTP- und MySQL-Server. Benutzernamen, Passwort, Port und Verzeichnisnamen ändern sich nicht. Auf dem Webspace installierte Scripte können weiterhin „mysql.lima-city.de“ als MySQL-Server-Namen verwenden. Diesen Hostnamen werden wir für jeden Benutzer auf den passenden MySQL-Server umschreiben, beim Premium-Paket ist das schon Praxis. Konfigurationsdateien müssen also nicht angepasst werden. Für 99% aller Benutzer besteht die einzige Umstellung darin, im FTP-Programm den Hostnamen von ftp.lima-city.de auf benutzername.lima-ftp.de zu ändern (man beachte den Unterschied zwischen lima-city.de und lima-ftp.de). Nur wenn „von außen“ (d.h. zuhause oder von anderen Webhosting-Anbietern) auf den MySQL-Server zugegriffen wird muss dort auch der MySQL-Server von mysql.lima-city.de auf benutzername.lima-db.de geändert werden.

Fragen beantworten wir gerne in den Kommentaren 🙂

Auf dem Webspace setzen wir derzeit die PHP-Version 5.4 ein, die nach dem 14.9.2015 keine Sicherheitsupdates mehr erhält.

Deshalb werden wir am 15.9. auf die aktuelle Version 5.6 upgraden, die derzeit noch unterstützt wird. Dazwischen liegt noch die Version 5.5, die zwar noch Sicherheits-Updates erhält, bei der aber keine Patches für Bugs mehr herausgebracht werden. Wir haben uns daher entschieden, diese Version zu überspringen.

Bitte prüfe, ob die von Dir eingesetzte Software mit PHP 5.6 kompatibel ist. Sofern Du dazu Software-Pakete wie WordPress, Joomla, WBB etc. installiert hast prüfe bitte auf Updates. Wenn Deine Scripte selbst geschrieben sind folge bitte den Migrations-Anleitungen von PHP für PHP 5.5 und PHP 5.6.

Möchtest Du Dich auch in einem öffentlichen WLAN in Deinen WordPress-Admin einloggen, aber sicher sein, dass Deine Zugangsdaten nicht mitgelesen werden? Das geht mit einer verschlüsselten Verbindung zu unserem Webspace. Unsere Community und auch unsere E-Mail- und FTP-Server unterstützen schon seit Jahren verschlüsselte Verbindungen.

Ab sofort bieten wir zusätzlich *kostenlos* einen verschlüsselten Zugriff per SSL/TLS auf den Webspace.
Das gilt für alle Subdomains von *.lima-city.de, das heißt: statt http://<username>.lima-city.de kannst Du nun einfach https://<username>.lima-city.de schreiben und der Browser baut eine verschlüsselte Verbindung zu unserem Webspace her.

Wenn Du eine eigene Domain hast, bieten wir dafür SSL-Zertifikate zum Kauf an: https://www.lima-city.de/ssl-zertifikate
Im Hilfe-Center beantworten wir einige Fragen, zum Beispiel wie Du automatisch auf SSL/TLS umleiten kannst und was „Mixed Content Warnings“ sind.

[Edit 24.7.2015] „SSL erzwingen“ ist als Option in der Verwaltung unter „Websites & Domains“ beim Bearbeiten einer Website verfügbar. Dadurch muss nicht mehr händisch eine .htaccess-Datei bearbeitet werden. Wir planen, demnächst in der Verwaltung zusätzlich eine Option „SSL erzwingen“ anzubieten, damit die Umleitung von der unverschlüsselten HTTP-Verbindung auf die verschlüsselte HTTPS-Verbindung auf Wunsch automatisch durchgeführt wird und nicht über die .htaccess-Datei eingestellt werden muss.

Wir möchten mit diesem Feature insbesondere die vielen kleineren Webseitenbetreiber unterstützen, die Verschlüsselung einsetzen möchten, aber das Geld für ein SSL-Zertifikat nicht ausgeben möchten oder können. Trotzdem sollen auch diese Webmaster nicht auf eine Verschlüsselung verzichten müssen.
Natürlich haben wir uns auch darüber Gedanken gemacht, dass wahrscheinlich Spammer und Phishing-Seiten dieses neue Feature von uns ausprobieren werden. Aber auf Abuse-E-Mails reagieren wir meist innerhalb von wenigen Minuten mit einer sofortigen Sperrung und wir rechnen nicht damit, dass dieser Aspekt zu Problemen führen wird.

Für weitere Subdomains bei uns, z.B. *.lima-city.at oder *.lima.zone werden wir in naher Zukunft kein SSL anbieten. Das hat hauptsächlich mit den Kosten für die Zertifikate zu tun, die bei der Anzahl der Domains für uns im vierstelligen Bereich liegen würden. Da jeder Benutzer eine *.lima-city.de-Subdomain bekommt ist aber damit die Versorgung aller User sichergestellt.

Was ist SSL?
Vereinfacht gesagt sichert ein SSL-Zertifikat Deine Kommunikation im Internet ab. Vergleichbar ist das mit dem Versiegeln eines Briefs, bevor Du ihn versendest. Wenn Benutzer sich auf Deiner Webseite anmelden oder persönliche Daten eingeben, möchtest du sicherstellen, dass die Daten nicht von jemandem (das könnte ein WLAN-Betreiber sein, oder jemand, der sich im gleichen Netzwerk befindet, oder auch Geheimdienste, die massenhaft das Internet überwachen) auf dem Weg vom Browser zu unserem Server mitgelesen werden können. Zudem garantiert SSL die Identität unseres Servers, sodass Dein Browser auch wirklich mit dem Server von lima-city spricht und nicht mit einem Angreifer, der die Verbindung „gekapert“ hat.

Wir werden am 9. März 2014 gegen 11:00 Uhr Wartungsarbeiten an einem Virtualisierungs-Server vornehmen. Die Wartungsarbeiten werden voraussichtlich 30-60 Minuten in Anspruch nehmen. Es werden einige Teile getauscht die Anzeichen von „Altersmüdigkeit“ zeigen. Für den Tausch einiger Komponenten muss der Server abgeschaltet werden. Davon werden folgende Dienste betroffen sein:

• Community und Verwaltung
• Jabber-Server
• E-Mail-Server
• Freespace

Der Premium-Webspace ist nicht betroffen. Auf der Community bzw. der Verwaltung und den betroffenen Webseiten auf dem Freespace wird ein Hinweis auf die Wartungsarbeiten und die voraussichtliche Restdauer angezeigt. Wir bemühen uns selbstverständlich die Ausfallzeit so kurz wie möglich zu halten.

Vielen Dank für das Verständnis.

Cronjobs sind zeitgesteuerte Kommandos, die ohne die „Aufsicht“ eines Benutzers laufen. Der Server führt in einem festgelegten Intervall ein vorgegebenes Kommando aus.

WordPress wird häufig ohne Cronjobs genutzt, so dass Wartungsarbeiten anders ausgeführt werden müssen. WordPress führt diese Wartungsarbeiten im Hintergrund aus, wenn der Blog besucht wird. Das Problem daran ist, dass die Seitenaufrufe von Besuchern durch die Wartungsarbeiten verlangsamt werden. Die Lösung des Problems ist es, einen „echten“ Cronjob einzurichten. Das ist nicht einmal schwer und in 5 Minuten erledigt!

lima-city bietet im Premium-Paket Cronjobs an. Für die folgende Anleitung wird vorausgesetzt, dass das lima-city Premium-Paket vorhanden ist.

Schritt 1: WordPress konfigurieren

Der erste Schritt ist denkbar einfach: WordPress muss wissen, dass es die Wartungsarbeiten nicht mehr im Hintergrund ausführen soll. Durch eine zusätzliche Konfigurations-Option lässt sich das einfach tun. Füge in der wp-config.php im Hauptverzeichnis Deines WordPress eine neue Zeile ein. Eine gute Stelle ist direkt über der folgenden Zeile:

/* That’s all, stop editing! Happy blogging. */

Die neue Zeile soll folgenden Inhalt enthalten:

define('DISABLE_WP_CRON', true);

Schritt 2: Cronjob einrichten

Nun sorgen wir dafür, dass regelmäßig die Wartung von WordPress durch einen Cronjob aufgerufen wird. Logge Dich dafür in der lima-city-Verwaltung ein und klicke im Menü auf „Cronjobs“.

Klicke anschließend auf den Button „Cronjob anlegen“.

In dem Formular für das Anlegen des Cronjobs sind zwei Angaben notwendig, die Ausführungszeitpunkte und die aufzurufende Adresse (URL).

Trage, wie abgebildet, folgende Werte ein:

Ausführungszeitpunkt: 0 * * * *
URL: http://www.example.com/wp-cron.php

Achtung: Ersetze bei der Adresse die Domain durch Deine WordPress-Adresse. Wenn Dein Blog unter http://www.example.com/blog/ o.ä. liegt, gib auch das Verzeichnis mit an!

Nach dem Speichern wird der Cronjob zu jeder vollen Stunde ausgeführt.

Und das war es auch schon! Die Ergebnisse jedes Aufrufs werden in der Verwaltung aufgezeichnet und können später für die Fehlersuche angeschaut werden. Schau einfach später noch einmal in die Verwaltung 😉

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!