Autor: Phillipp (Seite 10 von 20)

Jede Homepage braucht eine Adresse, vor allem eine, die einfach zu merken ist. Bisher haben wir davon eine ganze Reihe zur Verfügung gestellt in Form von „benutzername.lima-city.de“, „benutzername.lima-city.at“, „benutzername.lima.zone“ usw. Das führte dazu, dass der Benutzername plötzlich zentrales Element der Webseitengestaltung wurde und wir regelmäßig Fragen zur Änderung des Benutzernamen oder Einrichtung anderer Subdomains bekamen. Weil wir zuletzt auch noch kürzere Domains wie „benutzername.de.cool“ hinzugefügt haben, die mit der Beschränkung ihr Potenzial nicht ausschöpfen können (ich denke da an „ich-finde-schokola.de.cool“ o.ä.), möchten wir eine bessere Lösung finden.

Daher geben wir diesen Zusammenhang Benutzername/Subdomain nun auf. Ab sofort können für die Domains „de.cool“, „lima.zone“, „1337.pictures“, „clan.rip“ und „webspace.rocks“ beliebige Subdomains registriert werden (1337.pictures und clan.rip sind neu). Für die nächsten ca. 8 Wochen (bis zum 15.05.2016, 0:00) gibt es eine spezielle Phase („Sunrise-Phase“), in der die Benutzernamen anderer Accounts nicht registrierbar sind (Benutzer „hans“ kann nicht „peter.de.cool“ schnappen wenn der Benutzername „peter“ belegt ist, so dass „peter“ 8 Wochen Zeit hat um sich selbst „peter.de.cool“ zu registrieren). Damit hat jeder Zeit, seinen eigenen Benutzernamen zu registrieren. Ab dem 15.5. werden die Karten neu gemischt und es können alle Namen registriert werden.

Damit sinnlose Massen-Registrierungen verhindert werden (z.B. ein Benutzer registriert sich alle Städtenamen in der Form von bremen.de.cool, hamburg.de.cool etc.) beschränken wir die Anzahl aller kostenloser Subdomains pro Account zuerst auf 25 Stück. Wir werden nach ca. 3 Monaten prüfen ob das Limit von der Höhe und dem dahinter stehenden Gedanken sinnvoll ist und dann ggf. ändern oder aufheben.

Im Laufe der Zeit werden wir weitere Domains hinzufügen, daher: stay tuned und viel Spaß mit den neuen Subdomains!

Niemand mag es, es kostet viel Zeit und Nerven und einige wenige verdienen viel Geld damit. Die Rede ist von Spam. Wir bekommen nicht nur Spam, sondern wir versenden auch welchen. Nun ja, nicht direkt wir, und auch nicht freiwillig oder mit Absicht, aber es gibt Accounts bei uns, die nur zum Versenden von lästigen Botschaften angelegt werden. Andere Accounts bei uns werden wegen Sicherheitslücken oder schlechter Passwörter geknackt und dann zum Spam-Versand missbraucht.

Gegen all das kämpfen wir ständig an, und eines der Einfallstore möchten wir jetzt schließen. Es handelt sich um den Port 25. Ein Port identifiziert zusammen mit der IP-Adresse das Ziel einer Internetverbindung, 25 steht für „SMTP“: „Simple Mail Transfer Protocol“, einfaches E-Mail Transport-Protokoll (es gibt übrigens kein „kompliziertes E-Mail Transport-Protokoll“, E-Mail ist schon so komplex genug ;-)). Dieser Port wird von Spam-Versendern häufig und auch von unserem Webspace genutzt um gefälschte und ungewollte E-Mails bei anderen Mail-Servern über das Internet einzuliefern. Für den häufigsten Zweck, nämlich E-Mail über einen Server zu versenden, bei dem man ein „Kundenkonto“ bzw. einen gesicherten Zugang hat, gibt es aber einen anderen Port für das gleiche Protokoll (587/Submission). Es ist 100% kompatibel, da es ebenfalls SMTP ist und gleichzeitig fast immer so konfiguriert, dass vor dem Versand einer E-Mail geprüft wird, ob der Versender auch berechtigt ist über den Mail-Server zu versenden.

Da auch viele andere Provider, ob Webspace, Server oder Cloud, den Port 25 sperren und nur Mail-Versand per Port 587 erlauben, ziehen wir mit und machen das Internet damit ein bisschen Spam-feindlicher. Für legitimen E-Mail-Versand macht das keinen Unterschied.

Zum 1.4. werden wir daher über PHP das Herstellen ausgehender SMTP-Verbindungen zu Port 25 nicht mehr zulassen. Der Versand von E-Mails über SMTP ist selbstverständlich weiterhin möglich, dazu sollte allerdings der besser geeignete Port 587 (für Submission) verwendet werden, SMTPS (465) kann selbstverständlich auch genutzt werden. Und zu guter letzte bleibt auch die Möglichkeit, die PHP-Funktion mail() zu verwenden.

Bin ich betroffen?
Betroffen ist Dein Mail-Versand, wenn beide Voraussetzungen erfüllt sind: a) Du versendest per PHP E-Mails (z.B. über ein Kontaktformular, Bestellbestätigungen eines Shops, etc) b) Du hast den Versand über einen Mail-Server per SMTP eingestellt, z.B. über Deinen Account bei Googlemail oder web.de. Benutzer des Mail-Servers bei lima-city, der Versand über unseren Mail-Server oder der Versand von E-Mail über PHP-Mail sind nicht betroffen.

Was ändert sich für mich?
Wenn Du betroffen bist (siehe oben) musst Du nur die Port-Nummer in den Einstellungen des SMTP-Servers ändern. Dort sollte als Port „25“ eingetragen sein. Ändere diese Einstellung bitte auf „587“, aktiviere die Verschlüsselung (STARTTLS) und speichere die Änderung. Bitte denke auch daran eine Test-Mail zu senden. Das ist auch schon alles!

Ich verwende für den Versand per SMTP ein Postfach auf dem Mail-Server von lima-city. Bin ich auch betroffen?
Grundsätzlich schadet es nicht, wenn Du die Änderung vornimmst, da der Port 587 dafür semantisch besser passt. Der Mail-Server wird aber von uns nicht blockiert, da er in unserem eigenen Netz steht und entsprechend abgesichert ist.

Heute haben wir eine neue „Endung“ für die kostenlosen Subdomains hinzugefügt: „.de.cool“.

Damit können nun in der Verwaltung neue Subdomains in Form von „[benutzername].de.cool“ erstellt werden: in der Verwaltung unter „Websites & Domains“ auf „lima-city-Subdomain erstellen“ klicken und aus der Liste „[benutzername].de.cool“ auswählen. Nach dem Speichern ist die Domain innerhalb von ein paar Minuten aktiv. Selbstverständlich sind die Subdomains alle per SSL erreichbar.

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?„.