Ende letzten Jahres hat die Certificate Authority (CA) StartCom für einiges an Furore gesorgt, als diverse Verstöße gegen die Richtlinien bekannt wurden, nach denen eine CA Zertifikate ausstellen darf. Diverse Browser-Hersteller (Chrome, Firefox) und Betriebssysteme (iOS, Mac-Plattform) haben daraufhin StartCom und WoSign das Vertrauen entzogen. Von Startcom ausgestellte Zertifikate wurden teilweise nicht mehr akzeptiert oder nur noch mit bestimmten Bedingungen (z.B. nur, wenn sie vor einem bestimmten Datum ausgestellt wurden).

Auch wir haben Zertifikate von StartCom eingesetzt, um unsere kostenlosen Subdomains wie meinbenutzername.lima-city.de mit SSL-Zertifikaten zu versorgen.  Nun wurde immer deutlicher, dass die absolute Deadline, an dem die Zertifikate auch in den bisherigen Sonderfällen nicht mehr akzeptiert werden, bald erreicht wird und demnächst immer mehr Browser diese Verbindungen als „nicht sicher“ einstufen würden. Der erste Gedanke geht in dem Fall natürlich in Richtung von Let’s Encrypt, denn immerhin werden auch schon alle Kunden-Domains und aufgeschaltete Domains inklusive aller Subdomains vollautomatisch via Let’s Encrypt mit SSL-Zertifikaten ausgestattet. Wir können also unsere bisherige Infrastruktur zum Ausstellen von Zertifikaten mit Let’s Encrypt weiter nutzen und haben keine Kosten durch teuer gekaufte Wildcard-Zertifikate-

Es stellte sich aber schon im letzten Jahr schnell heraus, dass Let’s Encrypt ohne weiteres nicht die Lösung sein kann. Das Problem dabei, alle Subdomains unter lima-city.de und den anderen Domains (12hp.de, 12hp.at,  usw.) mit SSL-Zertifikaten auszustatten, liegt in den Limits von Let’s Encrypt, die es gleich auf mehrere Arten verbieten, viele Subdomains unter einer Domain anzulegen:

• es lassen sich nur 20 Zertifikate pro Woche für eine Domain ausstellen. Das heißt, wir hätten maximal 20x pro Woche neue Zertifikate ausstellen können. Rein rechnerisch könnten wir alle 8,5 Stunden ein neues Zertifikat ausstellen, neue Registrierungen müssten so lange auf ein Zertifikat warten. Das alleine ist schon sehr unangenehm.
• es sind maximal 100 Subdomains pro Zertifikat erlaubt. Rein rechnerisch lassen sich also 2.000 Subdomains einer Domain mit einem Zertifikat schützen. Das ist eindeutig zu wenig, wir liegen in einer Größenordnung von hunderttausenden Subdomains für lima-city.de.

Unglücklicherweise stellt Let’s Encrypt (bisher) keine Wildcard-Zertifikate aus, so dass es nur noch die Lösung gibt, die Rate Limits irgendwie zu umgehen. Let’s Encrypt stellt genau für solche „Anträge“ ein Formular zur Verfügung, was aber leider gänzlich im Sande verlief. Aber es gab noch eine weitere Lösung: die Public Suffix List.

Die Public Suffix List ist eine Liste von Domains, die von diversen Programmen, Firmen und Prozessen dazu genutzt wird, zu bestimmen auf welchem „Level“ eine Domain sich befindet, also was der „öffentliche“ Teil einer Domain ist. Beispielsweise bei .de-Domains ist klar, dass a.de und b.de nicht zusammen gehören – „de“ ist ein „öffentliches Suffix“. Bei a.co.uk und b.co.uk ist der öffentliche Teil analog „co.uk“. Es gibt auch „private“ Suffixe, wie z.B. dyndns.org, denn unter dyndns.org kann jeder eine eigene Subdomain registrieren.

Es stellte sich also heraus, dass auch Let’s Encrypt die Public Suffix List verwendet, um die Limits zu prüfen. Wenn also lima-city.de ein Public Suffix ist, dann gilt das Limit mit 2.000 Subdomains nicht für lima-city.de, sondern für jede einzelne Subdomain wie mustermann.lima-city.de – und da wir nur mustermann.lima-city.de und vielleicht noch www.mustermann.lima-city.de schützen wollen, reicht das Limit von 2.000 Subdomains gut aus. Gesagt, getan: wir haben unsere Domains in die Public Suffix List aufnehmen lassen (das dauerte einige Wochen), Let’s Encrypt hat nach ein paar weiteren Wochen die Änderungen der Public Suffix List übernommen und siehe da, unser System stellt nun fleißig neue Zertifikate für die Subdomains aus, so dass der Großteil der Subdomains nun mit Zertifikaten von Let’s Encrypt geschützt sind. Das StartCom-Zertifikat ist nur noch ein Fallback, falls bisher kein Zertifikat von Let’s Encrypt ausgestellt wurde. Wir sagen also derzeit für hunderttausende Adressen „Bye, Bye, StartCom!“ und „Hallo Let’s Encrypt“.

Es ist übrigens wahrscheinlich, dass wir die Verwaltung von Let’s Encrypt-Zertifikaten demnächst ganz aus der Verwaltung entfernen. Inzwischen werden alle Adressen, die auf unseren Systemen gehostet sind, automatisch mit Zertifikaten versorgt. Es ist schlicht nicht mehr nötig, selbst Zertifikate zu verwalten, da unser System diese ganze Arbeit vollständig und transparent übernimmt. SSL und der verschlüsselte Transport von Daten sollte nämlich Standard sein und keine Arbeit und Mühe erfordern.

Wir haben gerade 100 € für die Verfassungsklage von Digitalcourage e.V. gegen die Bundesregierung wegen des Staatstrojaners gespendet.

Der Verfassungstrojaner ist eine Schadsoftware, welche die Polizei und Geheimdienste auf den Computern von Verdächtigen installiert, beispielsweise in dem sie filmreif in die Wohnungen von Verdächtigen einbricht oder den Computer hackt. Einer der wichtigsten Punkte ist, dass dabei Sicherheitslücken ausgenutzt werden, die nur aus einem Grund nicht geschlossen werden: damit Geheimdienste und die Polizei besser Computer hacken kann. Wir schwächen also potenziell die IT-Sicherheit auf der gesamten Welt – und auch unsere eigene, man denke nur an Atomkraftwerke –  nur damit die Polizei und der Geheimdienst besser seine Bürger hacken kann.

Ein prominenter Fall dazu waren in letzter Zeit die Erpressungstrojaner „Petya“, „WannaCry“ und „NotPetya“, von denen weite Teile der deutschen Unternehmen massiv betroffen waren und der Millionen- bis Milliardenschäden verursachte. Der Trojaner nutzte Sicherheitslücken aus, welche die NSA genau aus dem gleichen Grund nicht an Microsoft meldete: um sie selber ausnutzen zu können. Wir müssen uns also fragen, ob wir auch direkt oder indirekt für solche Katastrophen durch staatliche Akteure verantwortlich sein wollen. Wir von lima-city denken, dass wir das nicht möchten. Die Sicherheit unserer Kundendaten und von allen IT-Systemen, egal ob in der Produktionsstraße von einem Industrieunternehmen, im Atomkraftwerk oder nur am Fahrkartenautomaten, ist uns wichtig, deshalb müssen wir uns im Notfall, auch und gerade für unsere Kunden, gegen den Staat wehren, sofern er die falsche Richtung einschlägt.

Deshalb appellieren wir an alle, ebenfalls einen kleinen Beitrag zur Klage von Digitalcourage e.V. zu leisten, damit es eine unabhängige Prüfung durch das Bundesverfassungsgericht geben kann. Danke!

Wir bekommen zwar einiges an Lob, aber ganz besonders schön war heute das Lob, dass unsere Seite auch mit Screenreadern gut funktioniert („für blinde Menschen zu 99% bedienbar“). Screenreader bzw. assistive Technologien helfen u.a. blinden Menschen, sich im Internet zurechtzufinden.

Es lohnt sich also, dass wir ARIA-Attribute setzen und sauberes Markup schreiben 🙂

Hier im Blog ist es derzeit etwas ruhiger als sonst. Das liegt nicht daran, dass es nichts zu bloggen gäbe, sondern, dass wir uns voll auf unsere kommenden Cloud-Services konzentrieren. Die Cloud ist ein wunderbarer Begriff, unter dem sich jeder etwas anderes vorstellt, aber alle in etwa den gleichen Kern meinen: „es kümmert sich jemand anderes darum“. Wobei das „darum“ immer verschieden ist, denn in der Cloud gibt es von Speicherlösungen über Projektmanagement-Software bis hin zum Cloud-Server so gut wie alles. Bei uns bilden Cloud-VPS auf Basis von KVM den ersten Baustein unseres Cloud-Stacks. Zuerst beginnen wir mit reiner IaaS (Infrastructure as a Service) und bieten nur „normale“ virtuelle Server (Cloud-VPS, Virtual Private Server) an. Im weiteren Verlauf kommen in mehreren Phasen noch weitere Infrastruktur- und Management-Tools dazu.

Die Cloud-VPS werden der grundlegende Baustein sein, auf dem alle anderen Cloud-Services fußen. Wir haben uns daher dazu entschieden, gar nicht erst zu versuchen, den niedrigsten Preis auf dem Markt zu bieten. Wir möchten ein solides, stabiles Produkt bieten, das für Wechsler vom klassischen vServer genauso einfach zu bedienen ist wie für Profis, die von der Colocation in die Cloud migrieren möchten. Die Abrechnung erfolgt dabei cloud-typisch pro Stunde, es gibt also keine Mindestlaufzeit von einem Monat, sondern es lässt sich auch problemlos ein neues Cloud-VPS zum Testen einer Software o.ä. erstellen und nach einer halben Stunde wieder löschen, wobei je nach Cloud-VPS nur wenige Cent Kosten anfallen. Einen neuen Cloud-Server erstellt unser System in ca. 50-60 Sekunden, also deutlich schneller als die Bereitstellungszeit klassischer vServer bei dem durchschnittlichen Webbhosting-Provider. Mit Snapshots lassen sich Cloud-VPS natürlich auch klonen, so dass z.B. ein größeres Software-Upgrade vorab in einem geklonten Testsystem ausprobiert werden kann.

Die Hardware der Cloud-VPS steht ebenfalls in unserer Colocation im Telehouse Frankfurt (als angehender Cloud-Provider müssten wir diese Colocation nun „FRA1“ nennen ;-)). Wir verwenden für die Hypervisor (Host-Systeme) ausschließlich HP Enterprise-Hardware und hochwertige Netzwerk-Anbindung. Diesen ersten Baustein unseres Cloud-Stacks haben wir nun also intensiv vorbereitet und getestet. Viele interne Services, wie auch unsere Master-Datenbank, haben wir bereits dorthin migriert (wir essen, was auch beim Kunden auf den Tisch kommt). Von einigen ersten Beta-Kunden haben wir schon viel positives Feedback bekommen. Das System hat also Produktionsreife und damit starten wir nun in eine private Beta, um die letzten Kleinigkeit, auch in der Control Panel, zu finden und zu beseitigen, herauszufinden was die häufig gestellten Fragen sind, welche Themen wir mit Hilfe-Artikeln unterstützen müssen usw.

Zugang zur Private Beta kann in der Verwaltung unter dem neuen Menüpunkt „Cloud-VPS“ angefragt werden. Wir schalten die Beta-Anfragen (von denen wir schon einige in der ersten halben Stunde nach der Freischaltung des Menüpunkts bekommen haben) manuell frei und versenden dann eine Benachrichtigung per E-Mail. Wer also Interesse hat, einmal nachzusehen, was wir da treiben darf gerne klicken, wir freuen uns über alle Anfragen und natürlich über Anregungen, Wünsche und Fragen! Happy Testing!

Lange, lange haben wir keinen Support per Telefon angeboten, aber manchmal merkt man schon, welchen Wert so ein persönliches, interaktives Gespräch im Gegensatz zu E-Mail-Ping-Pong hat. Einerseits lernt man sich besser kennen, andererseits gehen dort manche Erklärungen und Lösungen viel schneller.

Deswegen werden wir nächste Woche experimentell unter der Nummer 0421/40 89 99 94 mit Telefon-Support starten, von ca. 9:00 – 20:00, allerdings nicht ständig besetzt.

Dazu kommt noch ein Kontaktformular auf der Webseite (ja, hatten wir auch nicht, sondern nur die E-Mail-Adresse des Support), wo als Kontaktwunsch dann E-Mail oder Rückruf gewählt werden kann. Und natürlich, *wann* denn ein Rückruf gewünscht ist: Morgens, Mittags, Abends, …

Der Rückruf ist gerade für uns mit einem kleinen Team sehr praktisch, da wir dann immer noch konzentriert an einer Sache arbeiten und dann gesammelt einen ganzen Stapel Anrufe erledigen können. Ständige Unterbrechungen durch Anrufe können wir so ein bisschen abfedern. Natürlich ist es trotzdem möglich, einfach den Hörer in die Hand zu nehmen und uns anzurufen.

In diesem Sinne: vielleicht hört man sich ja demnächst. Und bis dahin noch ein schönes Wochenende!

Ich bin gerade etwas erschrocken über eine Support-Anfrage, bei der absolut nicht klar ist, ob sie Spam oder eine echte Support-Anfrage ist.

Leider kommen immer wieder vereinzelte Support-Tickets mit einem solch niedrigen Niveau herein, dass man den Kunden eigentlich alles zutraut…

… hatte ich damals auch in der Grundschule. Ob es damals Sponsoren gab, weiß ich nicht mehr. Heutzutage gibt’s auf jeden Fall welche, und wir haben auch einen kleinen Beitrag dazu geleistet und Verkehrserziehungs-Hefte für die Verkehrswacht Bremen gesponsert. Und so sieht das dann aus:

Auf unseren Premium-Servern hatten wir Anfang des Jahres wirklich heftige Probleme mit ständigen Abstürzen, die sich nicht erklären ließen. Aus heiterem Himmel fingen die Server an, sich immer wieder komplett aufzuhängen, ganz offensichtlich wegen Problemen mit IO. Der Verdacht fiel auf die RAID-Controller von Adaptec, und wochenlang haben wir alle möglichen Probleme analysiert, die sich im Internet dazu finden ließen, Workarounds ausprobiert und sogar mit Energiespareinstellungen experimentiert, es half alles nichts. Und das merkwürdigste: Wochen vorher gab es diese Probleme noch gar nicht. Wenn vorher die Server hunderte Tage problemlos liefen, schaffte es nun kaum eins der Systeme, mal 30 Tage am Stück durchzuhalten, teilweise nur wenige Tage. Im Support wurde das immer peinlicher, es war unmöglich eine Aussage zu Ursache und Behebung zu machen und es musste dringend eine Lösung her.

Also wurde ein Testsystem abgestellt, aber auf dem ließen sich die Fehler nicht reproduzieren. Erst auf einem zweiten Testsystem, diesmal ohne RAID-Controller, kam durch Zufall ein relativ zuverlässiger Test zustande (ein Mischung aus fio und dd), wie das Problem nachzustellen war. Und dann war auch klar: es kann nicht der Controller sein. Es war ein Deadlock im Linux-KernelModul bcache. Nach ein paar Minuten IO-Last hing sich das System einfach auf, und zwar dann, wenn es Daten von einer Cache-SSD auf eine HDD geschrieben hat, während die Geschwindigkeit, mit der das passieren soll, im gleiche Moment neu berechnet wurde.

Mit dem zuständigen Kernel Maintainer ließen sich dann zwei potenzielle Quellen für das Problem finden, und mit ein bisschen Feintuning an Kernel-Parametern konnte ich das Problem auf eine der beiden Stellen eingrenzen. Zum Glück war es möglich, das Problem (auf Kosten der Schreib-Performance) durch weiteres Tuning dieser Parameter abzustellen. Ich habe mir dann lang und breit erklären lassen (müssen), was der Code zu welchem Zweck tut, und der Fix war unfassbar simpel: eine Sperre (genauer gesagt eine reader/writer semaphore), die eigentlich komplett unnötig war und nur „weil man ja nie weiß“ vorhanden war, produzierte das Problem. Zwei Zeilen Code gelöscht, Kernel kompiliert, und schon war das Problem auf dem Test-System, auch nach Tagen von IO-Volllast, verschwunden.

Kurz darauf hatte ich schon geplante Wartungsarbeiten angesetzt, so dass der gepatchte Kernel zumindest auf einigen Systemen produktiv gehen konnte, und siehe da: keine Abstürze mehr. Adaptec (die RAID-Controller) war also doch nicht schuld, der Kernel war es! Warum allerdings das Problem seit kurzem so häufig auftrat und vorher nicht, das bleibt ein Rätsel.

Und so kommt es, dass ich demnächst meinen ersten – und ehrlich gesagt ziemlich kurzen, da er nur zwei Zeilen löscht – Patch für den Linux-Kernel einreichen kann. Und zumindest für mich ist es schon ein kleiner Ritterschlag, dass mein Code (oder mein Entfernen von Code) in den Kernel aufgenommen wird und auch noch so ein ekeliges Problem löst. Wäre das Problem nicht wirklich unangenehm gewesen und hätte mir unzählige schlaflose Nächste bereitet hätte zumindest die Jagd nach dem Fehler fast Spaß gemacht, denn in manchen Informatikern steckt einfach ein kleiner Sherlock Holmes, der erst dann zufrieden ist, wenn er den Fall löst. Und das ist bei mir definitiv der Fall 😉

Und der hilfreiche Kernel Maintainer bekommt zum Dank – er erwähnte eine spezielle Scotch-Sorte, die er gerne trinkt – ein Paket nach Alaska geschickt. Denn dort (für mich ist dort in etwa das Ende der Welt) hat man scheinbar viel Zeit, um das wie, was und warum von  Linux-Kernel-Code zu erklären, und dafür möchte ich mich gerne bedanken!

Ende letzten Jahres habe ich begonnen, Freitags einen „Rückblick auf die Woche“ zu schreiben, der im Wesentlichen aus den neuen Features bestand, die wir in der Woche hinzugefügt haben. Das kam gut an, war aber für uns leider nicht so einfach. Ich musste mindestens einen vollen Tag der Woche für die Vorbereitung dieses Posts aufwenden: nicht in jeder Woche haben wir neue Features, da wir auch mal an Updates, Bugfixes, technischen Aufräum-Arbeiten etc. arbeiten müssen. Und das ist ein deutlich größerer Teil ist als die Umsetzung neuer Features. Deshalb fing am Donnerstag oder Freitag die Suche an, was denn diese Woche noch in den Blog-Post kommen könnte. Und andere Dinge blieben dafür liegen, dass wir noch 1-2 Punkte auf die Freitags-Update-Liste setzen konnten.

Deshalb überlegen wir uns nun, wie dieses Format anders aussehen könnte, z.B. im Rhythmus von 2 Wochen, oder wir legen den Fokus mehr darauf, ein bestimmtes Feature vorzustellen, oder zusätzlich über bestimmte aktuelle interne Themen (sofern sie relevant sind, wie z.B. aktuelle DDoS-Wellen, etc) zu berichten.

Hast Du auch eine Idee? In den Kommentaren ist Platz dafür, und vielleicht können wir den Wunsch erfüllen!

In einer Woche ist Weihnachten, aber wir haben heute schon Geschenke für euch! Heute verlosen wir drei komplette Hosting-Pakete für ein Jahr! Dieses beinhaltet eine .de/.at./.ch/.eu/.com/.net/.org-Domain (nach Wahl), sowie das lima-city Premium-Paket für ein Jahr lang kostenfrei. Dazu gibt es noch eine lima-city-Tasse frei Haus!

Einfach hier bis zum 19.12., 18:00 kommentieren, den Beitrag auf Facebook teilen oder auf Twitter retweeten und schon kommst Du in den Lostopf!