Autor: Phillipp (Seite 1 von 16)

Updates KW37

Wieder geht eine spannende Woche dem Ende entgegen. Auch diese Woche haben wir kräftig für euch in die Tasten gehauen. Im Blog haben wir eine kurze Analyse zu den Upload-Filtern veröffentlicht. Ein heißes Thema, aber unserer Auffassung nach wird’s nicht so heiß gegessen, wie es gekocht wird. Es handelt sich immerhin nur um einen Entwurf für eine Richtlinie, über die verhandelt werden soll. Das Internet ist noch nicht tot, genauso wenig wie damals in den Neunzigern (na, wer kann ich noch erinnern?) nach dem Urteil des LG Hamburg zur Linkhaftung 🙂

Ich beginne mit den „Kleinigkeiten“ und komme dann zu dem längeren Teil, der Einführung von Datenbank-Benutzern.

Wir haben die API-Dokumentation angepasst. In der Version 1.0.1 (OpenAPI Viewer) ist die Möglichkeit dazugekommen, DNS-Records für Domains per API zu verwalten.

Um Missbrauch der E-Mail-Services vorzubeugen haben wir eine neue „Warmup-Phase“ für Domains eingeführt. Wenn eine Domain neu registriert, transferiert oder aufgeschaltet wird, ist sie nun für eine Woche in einer „Warmup“-Phase, in welcher nur 50 E-Mails pro Tag für die neue Domain verschickt werden können (über alle Postfächer der Domain). Nach einer Woche – oder einer kurzen Nachricht an den Support – wird dieses Limit aufgehoben. Dies verhindert, dass mit geklauten Kreditkarten-Daten oder PayPal-Accounts eine Domain registriert wird, bei welcher sofort über Dutzende Postfächer Unmengen an E-Mails verschickt werden. Schöne Grüße an die Spammer aus Frankreich 😉

Bei den Cloud-VPS wurde die Lease-Zeit von IP-Adressen per DHCP auf einen Tag verkürzt, vorher war sie unbegrenzt. Das führte zu dem Problem, dass einige Cloud-VPS keine IP-Adressen per DHCP bekommen haben, weil noch ein Lease für eine andere MAC-Adresse bestand. Danke an Christoph für den Hinweis.

Einführung mehrerer Datenbank-Benutzer

In Zusammenhang mit den Änderungen an den Datenbanken, welche wir vor zwei Wochen umgesetzt haben, gibt es nun auch die angekündigten Neuigkeiten bei den Datenbank-Benutzern. Wir haben alle Vorbereitungen abgeschlossen, um mehrere Datenbank-Accounts mit individuellen Rechten zu erstellen. Die Menüs in der Verwaltung sind dafür noch nicht freigeschaltet, da wir noch ein paar Dinge testen und evaluieren müssen. Wahrscheinlich geht die Änderung Hand in Hand mit dem Release der neuen Verwaltungsoberfläche.

Für alle Kunden, die zum Zeitpunkt der Umstellung eine Datenbank besaßen, haben wir den Standard-Benutzer, den sie auch bisher verwendet haben, erstellt. Die Datenbank-Benutzer haben ein frei wählbares Suffix, also das Format lautet USER[Kundennummer] (z.B. USER795) und mit Suffix USER[Kundennummer]_[Suffix], also USER795_blog.

Die Rechtevergabe für Datenbank-Nutzer hat zwei Modi:

  • einfacher Modus („Simple-Mode“): die Rechte des Datenbank-Nutzers gelten für alle Datenbanken, ich in Zukunft erstellte. Es gibt 4 Rollen, welche die Berechtigungen regeln:
    • Administrator (alle Rechte – Select Insert Update Delete Create Drop Grant References Index Alter Lock_tables Create_view Show_view Create_tmp_table Event Trigger Create_routine Alter_routine Execute)
    • Lese-Schreib-Zugriff (Select Insert Update Delete)
    • Lese-Zugriff (Select)
    • keine Rechte (USAGE) – ideal für Monitoring-Scripts
  • erweiterter Modus: für jede Datenbank können die Rechte einzeln eingestellt werden

Warum werden MySQL-Passwörter nicht mehr angezeigt?

Im Gegensatz zu der bisherigen Implementierung speichern wir die Passwörter für MySQL-Datenbanken nun verschlüsselt (gehasht mit der MySQL-Passwort-Funktion, wenn man genau sein will). Yep, wir haben vorher die Passwörter für den Datenbank-Zugang in unserer Datenbank gespeichert. Asche auf unser Haupt. Plesk macht das übrigens immer noch so.

Die verschlüsselte Speicherung erhöht zwar die Sicherheit, falls mal unsere Datenbank geknackt werden sollte, führt aber auch zu ein-zwei neuen Problemen: wir können das Passwort nun nicht mehr in der Verwaltung anzeigen. Du kannst nur ein Passwort neu setzen, aber nicht herausfinden, was das aktuelle Passwort ist (außer, Du ziehst Deine Konfigurationsdateien heran, die enthalten ebenfalls das Passwort).

Eine Lösung dafür ist es, einfach einen neuen Datenbank-Benutzer mit einem bekannten Passwort anzulegen, den neuen Datenbank-Benutzer dort zu verwenden, wo er benutzt werden soll, und anschließend den bisherigen Datenbank-Nutzer – sofern er nicht mehr verwendet wird – zu löschen.

Der automatische Login in den phpMyAdmin funktioniert dadurch aber ebenfalls nicht mehr, da wir das Passwort nicht an den phpMyAdmin übermitteln können, wir kennen es ja selbst nicht mehr. Das werden wir voraussichtlich – ebenso wie temporären Zugriff für den Support – mit temporären Usern regeln. Wir würden dann einen Admin-User anlegen, der nach einer Stunde oder 3 Stunden automatisch gelöscht wird, und für den wir das Passwort kennen.

Erstellt der Software-Installer automatisch einen Datenbank-Benutzer?

Ja. Der Software-Installer fragt weiterhin nur nach der Datenbank, welche verwendet werden soll. Es kann eine bestehende Datenbank ausgewählt oder eine neue Datenbank erstellt werden. In beiden Fällen wird ein neuer Datenbank-User nach dem Schema USER[Kundennummer]_sw[nummer], also z.B. USER795_sw1 erstellt. Dieser Datenbank-Nutzer erhält Admin-Rechte auf die gewählte oder neu erstellte Datenbank.

Was denkst Du über die Änderungen? Schreibe uns eine E-Mail an den Support, hinterlasse einen Kommentar oder schicke uns eine DM auf Twitter 🙂

Ich wünsche ein schönes Wochenende!

Upload-Filter und Webhosting: sind Webseiten betroffen? Eine kurze Analyse

Wer die Nachrichten verfolgt wird es schon gelesen haben: das Urheberrecht soll reformiert werden. Das EU-Parlament hat heute zugestimmt, dass Verhandlungen für eine solche Reform zwischen dem Parlament und dem europäischen Rat stattfinden sollen. 438 Abgeordnete stimmten dafür, 226 dagegen und 39 enthielten sich.

Beschlossen wurde erst einmal ein Entwurf für den Text einer EU-Richtlinie, über welche der Trilog (EU-Kommission, EU-Parlament und EU-Rat) nun verhandeln. Also eigentlich noch nix.

Die großen Streitpunkte sind dabei der Artikel 13 („Upload-Filter“) und Artikel 11 („Leistungsschutzrecht“). Ein Pressespiegel:

Warum die ganze Aufregung?

Wie wir es häufig in politischen Diskussionen der vergangen Zeit sehen, scheint es nur schwarz und weiß zu geben. Kritiker sehen das freie Internet in Gefahr, Befürworter möchten, dass organisierte Rechteinhaber (z.B. GEMA) bei den Online-Portalen am Umsatz beteiligt werden. Urheber würden zu wenig Geld verdienen und müssten an den Umsätzen beteiligt werden.

Die sachliche und inhaltliche Diskussion bleibt dabei leider ein wenig auf der Strecke. Schauen wir uns doch genauer an, was überhaupt im Entwurf steht – denn schließlich wird darüber berichtet, nur den Text bekommt man selten zitiert. Im Rechtsinformatik-Kurs meines Studiums sagte unser Professor, der wunderbare Jürgen Taeger, immer:

„Ein Blick in’s Gesetz erleichtert die Rechtsfindung“

In diesem Fall wollen wir uns einfach mal ansehen, mit welchen Auswirkungen wir anhand des derzeitigen Entwurfstextes als Webhosting-Provider rechnen können. Dazu ziehen wir den folgenden Bericht (Report) heran:

Report on the proposal for a directive of the European Parliament and of the Council on copyright in the Digital Single Market

Was bedeutet der „Upload-Filter“?

Das Schlagwort in der Berichterstattung ist der „Upload-Filter“. Kritiker befürchten, dass Plattformen in Zukunft alle Inhalte filtern werden, bevor sie sie veröffentlichen. Die Gefahr dabei ist, dass auch Kleinigkeiten, die urheberrechtlich geschützt sind, zu dem Blockieren eines neuen Werks führen. Damit ist gemeint, dass beispielsweise bei einem Video aus einem Café die Hintergrundmusik des Cafés den Filter dazu verleitet, das Video zu sperren. Oder der Filter erkennt schlicht etwas falsch, was gar nicht urheberrechtlich geschützt ist. Das kennt man unter dem Begriff „Overblocking“. Die Aufgabe zu Filtern in die Hand von privaten Unternehmen zu legen ist ein weiteres Problem (siehe „Warum ist es schlecht, wenn Unternehmen Inhalte filtern?“).

Das Wort „Filter“ kommt im Entwurfstext allerdings nur an einer Stelle vor. Der Witz ist, an welcher Stelle „Filter“ erwähnt werden: es wird im Entwurfstext vor Filtern gewarnt. Es wird also explizit auf diesen größten Kritikpunkt der Gegner dieser Direktive – das „Overblocking“ –  eingegangen:

The use of filtering potentially harms the interests of users, as there are many legitimate uses of copyright content that filtering technologies are often not advanced enough to accommodate.

Es ist also nicht so, als würde dieser Aspekt nicht gesehen. Auch die Haftungsprivilegierung von Internet-Providern (EU-Richtlinie 2000/31/EC, Electronic Commerce Directive) und deren enorme positive Bedeutung für das Internet wird dort erwähnt. Dass dieser Aspekt nicht verändert werden soll ist dort auch angesprochen:

[..], this should be achieved without negative impacts on the digital economy or internet freedoms of consumers.

Wir können also davon ausgehen, dass der Trilog die Filter, ihren Effekt auf die Meinungsfreiheit und speziell Overblocking in die Verhandlungen mit einbeziehen wird.

Warum ist es schlecht, wenn Unternehmen Inhalte filtern?

Wenn die Entscheidung, welche Inhalte zu blockieren sind, an private Unternehmen ausgelagert wird, hat dies mehrere Probleme:

  1. Unternehmen haben kein Interesse, die „richtige“ Entscheidung zu treffen. Für ein Unternehmen, welches entscheiden soll, ob Inhalte rechtlich zulässig sind oder nicht, ist dies an erster Stelle Aufwand, und der kostet Geld. Ein Mensch, der dafür beschäftigt wird, müsste für Dutzende oder Hunderte Länder die Rechtslagen kennen und die Fähigkeiten und Zeit haben, diese gegeneinander abzuwägen. Das erfordert sprachliche und juristische Fähigkeiten und ist prinzipiell Arbeit von Gerichten, nicht von Mitarbeitern in privaten Unternehmen.
  2. Unternehmen möchten Risiko minimieren. Wenn beispielsweise YouTube aufgefordert wird, ein Video wegen Urheberrechtsverletzungen zu sperren, und für eine Zuwiderhandlung mit einer hohen Strafe bedroht wird, das Sperren aber gar keinen Nachteil hat, weil das Video nur ein paar Cent Werbe-Umsatz macht, was wird wohl die Entscheidung sein? Man kann davon ausgehen, dass YouTube hier nicht den Rächer der Enterbten spielen wird (außer man meint mit „dem Enterbten“ den Urheber). Ein Sperren ist aus Sicht des Unternehmens die günstigste (=billigste) Lösung, da keine Gefahr von hohen Strafen durch Urheber droht. Schadensersatz dafür, dass man seine Meinung zu Unrecht nicht veröffentlichen durfte, gibt es nicht.
  3. Unternehmen lagern Entscheidungen gerne an Software-Filter aus. Da menschliche Arbeit teuer ist, wird die Arbeit, Inhalte zu bewerten, gerne an Software ausgelagert. Die Filter treffen in komplexen Systemen komplexe Entscheidungen die schwerer zu durchschauen sind als man denkt (siehe auch das folgende Video).

Untermauern wir das doch mit einem Beispiel aus der Praxis: der deutsche YouTuber LeFloid berichtet in einem Interview (ab ca. 7:28) davon, wie kafkaesk dieses Zusammenspiel von automatischen Filtern und menschlichen Entscheidungen ist.

Wir können davon ausgehen, dass es genau diese Probleme sind, welche auch im Bericht als „negative impacts“ erwähnt sind. Die Meinungsfreiheit ist in der Grundrechtecharta der EU festgelegt, ignorieren können (oder sollten) diese Bedenken also weder der Rat, die Kommission noch das Parlament.

Sind Webhoster, und damit meine Webspace-Inhalte betroffen?

Nein. Ein Webhoster fällt nämlich nicht unter die Definition eines „online content sharing service provider“: ein „online content sharing service provider“ ist, wer aktiv Inhalte verfügbar macht, „optimiert“ und vermarktet um damit Gewinne zu erzielen:

The definition of an online content sharing service provider under this Directive shall cover information society service providers one of the main purposes of which is to store and give access to the public or to stream significant amounts of copyright protected content uploaded / made available by its users and that optimise content and promotes for profit making purposes, including amongst others displaying, tagging, curating, sequencing the uploaded works or other subject-matter, irrespective of the means used therefor, and therefore act in an active way. As a consequence, they cannot benefit from the liability exemption provided for in Article 14 of Directive 2000/31/EC.

Ein Webhosting-Provider ist (im Gegensatz übrigens zu Cloud-Providern, Online-Festplatten und Access Providern, die komplett von der Richtlinie ausgenommen sind) gar nicht relevant für die Richtlinie. Es geht hier nur darum, Plattformen, welche aktiv mit dem Content arbeiten, zu verpflichten. Das ist beispielsweise YouTube: YouTube erzeugt Tags, kuriert Inhalte, sequenziert, also legt Playlisten an, usw. um damit (mehr) Geld zu verdienen.

Ein Webhoster hingegen wird niemals die Daten seiner Kunden katalogisieren, zusammenfassen, aufbereiten, in Playlisten organisieren usw. um damit Geld zu verdienen. Das will und darf er gar nicht – aufgrund der europäischen Datenschutzgrundverordnung. Sofern er nämlich ein Auftragsverarbeiter nach Art. 28 DSGVO sein möchte (und das möchte er ganz bestimmt!) wird er sich davor hüten, irgendwie die Daten seiner Kunden zu verarbeiten. Eine solche Verarbeitungstätigkeit ist beispielsweise das Kategorisieren, Zusammenfassen oder Aufbereiten von Daten. Dabei sind nur personenbezogene Daten gemeint, aber ein Webhoster muss potenziell alle Nutzdaten seiner Kunden als personenbezogene Daten behandeln.

Ein Webhoster wird also per se nicht das tun, was unter die Definition eines „content sharing service provider“ fällt. Damit wird der Entwurf, so wie er ist, keine Auswirkungen auf Webhoster haben.

Werden Erinnerungen wach?

Werden hier gerade bei dem ein oder anderen Erinnerungen wach? Hatten wir das nicht schon mal? Sollte die Welt nicht schon im Mai untergehen, als die EU-DSGVO eingeführt wurde? Wo auch ganz viel und laut geschrien und Panik gemacht wurde? Am Schluss ist die Welt doch noch nicht untergegangen.

Vielleicht ist das eine Lehre, die in der aktuellen Zeit nützlich ist: nichts wird so heiß gegessen, wie es gekocht wird. Und was genau beschlossen werden soll ist viel leichter zugänglich, als man sich das denkt. Wenn man den Text selber liest, hört sich das alles gar nicht so schlimm an. Und wenn es sich doch schlimm anhört, dann kann man jederzeit seinen EU-Abgeordneten (MEP) im Parlament finden, kontaktieren und mit ihm über die Sache reden!

Fragen? Anregungen? Andere Meinung? Dafür sind die Kommentare da!

Updates KW 36

Während wir weiter an dem neuen Menü für die Verwaltung arbeiten (ich erwähnte das bereits im Update letzte Woche) haben wir uns viel Zeit genommen um die Webseite und besonders die Hilfe-Artikel zu pflegen. Leider hatten wir diese Woche einige Probleme mit Spammern und Fraud (besonders Kreditkartenbetrug), was einiges an Zeit und Nerven gekostet hat. Wir würden unsere Zeit lieber in die Entwicklung von unserem Hosting investieren, anstatt Kreditkartentransaktionen rückabzuwickeln und Fake-Bestellungen zu sichten.

Trotzdem haben wir 77 große und kleine Änderungen an der Webseite vorgenommen, von Verbesserungen der Navigation in der Hilfe und Überarbeitungen der Hilfe-Texte und -Kategorien über bessere Verlinkungen von relevanten Inhalten und Anpassungen von Texten, bis hin zum Austausch von Grafiken und Icons. Für einige weitere Seiten gab es zudem noch Mobile-Optimierungen.

Die Änderungen verbessern unter anderem auch Google-Suchtreffer, wenn Hilfe-Artikel gesucht werden. Die Suche nach „lima-city $thema“ zeigt nun mehr und relevantere Hilfe-Artikel an, auch wenn es noch einige Zeit dauern wird, bis Google alle Änderungen übernimmt. Zudem gab es auch Änderungen an der Verwaltung, wenn auch nur sehr wenige – es gibt momentan auch kaum bekannte Probleme, die sich noch beheben ließen:

Verwaltung:

  • Bugfix: Preise, welche mit mehr als zwei Nachkommastellen angezeigt werden sollten (z.B. der Preis/Stunde für Cloud-VPS) wurden nur 2 Nachkommastellen angezeigt
  • Bugfix: der nicht funktionierende Button „ein weiteres Postfach erstellen“ wurde vorerst entfernt
  • Verbesserung: die AuthInfo (AuthCode) für Domains kann nun per Verwaltung ausgestellt werden, es ist kein Formular mehr nötig.

Es sind derzeit noch ein Bug bei den Cloud-VPS bekannt: einige Cloud-VPS bekommen keine IP per DHCP. Im Normalfall stört das nicht, da wir die VPS mit statischer IP-Konfiguration installieren. Die Problemlösung wird in den Updates der nächsten Woche hier auftauchen.

Feedback? Fragen? Anregungen? Bug gefunden? Schreibe einen Kommentar oder eine E-Mail an den Support! Natürlich kannst Du uns auch auf Twitter folgen. Wir sind dankbar für jedes Feedback!

Ich wünsche noch ein schönes Wochenende!

Updates KW 35: Bugfixes beim Restore und Umlauten in Dateinamen

Vor drei Tagen haben wir angekündigt, in Zukunft allen Kunden mit kostenlosem Webspace unter anderem unbegrenzt MySQL-Datenbanken kostenlos zur Verfügung zu stellen. Ein großer Teil dieses Update-Blogposts würde von diesen Änderungen eingenommen werden, die ich aber überspringe. Es ist relativ unspektakulär, weil sich wenig geändert hat, sondern einfach nur viel Code gelöscht wurde. Schön war es auf jeden Fall, einmal zu sehen dass Komplexität entfernt wird, anstatt dass immer mehr dazu kommt. Die Liste ist dadurch heute kürzer.

Also nun zu den anderen Änderungen, die sich diese Woche ergeben haben.

Verwaltung:

  • Verbesserung: der Versand von Zahlungserinnerungen berücksichtigt nun Kunden, deren Rechnungen per Lastschrift eingezogen wurden und bei welchen sich das Datum der Lastschrift sich nach hinten verschoben hat (wenn der originale Fälligkeitstermin des Einzugs kein TARGET-Tag ist)
  • Bugfix: Domains, die aufgeschaltet wurden und während sie als Domain aufgeschaltet waren, zu lima-city umgezogen wurden, sind weiterhin als aufgeschaltete Domain behandelt worden. Das Problem ist gelöst.
  • Verbesserung: die Breadcrumbs-Navigation der Hilfe-Seiten wurde verbessert, so dass in Google-Suchergebnissen zur Verbesserung der Übersicht die Kategorie angezeigt werden sollte

Infrastruktur:

  • Bugfix: beim Entpacken von ZIP-Dateien mit „unzip“ werden Umlaute in Dateinamen nun korrekt entpackt. Zudem werden nun alle „de_*“-Locales generiert
  • Bugfix: beim Wiederherstellen von Backups mit Dateinamen, welche Umlaute/Sonderzeichen enthalten, wurden die Umlaute „escaped“ wiederhergestellt (z.B. „T#U00c3a4st.txt“ für „Täst.txt“)
  • Bugfix: beim Wiederherstellen von Datei-Backups wurden wiederhergestellte Verzeichnisse, welche in zweiter Ebene („username/ebene1/ebene2“) liegen und nicht existieren, als „root“ angelegt und nicht als Kunde
  • Bugfix: beim Buchen eines neuen Webhosting-Pakets wurde die Quota auf dem Webhosting-Server nicht in allen Fällen gesetzt

Danke an Jonathan für die Geduld mit (und das Melden, natürlich!) dieser Reihe ganzen Reihe von Umlaut-Bugs!

Unser Grafik-Designer Lennart lobbyiert unterdessen fleißig für eine Überarbeitung des grünen Header-Bereichs und hat sein Ziel schon fast. Zusammen mit der Navigation der Verwaltung (die an manchen Stellen echt gruselig ist, wenn man es genau betrachtet) werden wir also ein wenig fundamentalere Änderungen am Design umsetzen. Das ist ein weiteres der drei Projekte, welche ich letzte Woche erwähnt habe. Die Verwaltung soll sich in Zukunft mehr an anderen, ähnlichen Verwaltungsoberflächen orientieren: Google Developer Console, Google Search Console und Facebook Adsmanager sind gute Beispiele dafür, in welche Richtung sich das entwickeln wird.

Feedback? Fragen? Anregungen? Bug gefunden? Schreibe einen Kommentar (noch weiter nach unten scrollen 😉 !) oder eine E-Mail an den Support! Natürlich kannst Du uns auch auf Twitter folgen. Ich wünsche noch ein schönes Wochenende!

Änderungen an MySQL-Datenbanken, E-Mail und externen Domains

lima-city bietet seit dem Beginn in 2003 kostenlosen Webspace, Domains und bezahltes Webhosting an. Wir haben in den vergangenen 15 Jahren eine unglaubliche Transformation von einem Hobby-Projekt zu einem zuverlässigen und professionellen Webhoster für Privat- und Business-Kunden durchgemacht. Im Gegensatz zu etwa 99% der Webhoster auf dem deutschen Markt setzen wir keine Standard-Software wie cPanel oder Plesk ein, sondern haben mit großem Aufwand eine eigene Hosting-Plattform entwickelt. Dies hat uns zu Anfang ermöglicht, sehr kostengünstig viele kostenlose Accounts zu hosten, was uns unter anderem das Webhosting für Bildungsträger ermöglicht. Auch auf Trends können wir schnell reagieren – und tun es auch: wir haben ein spezielles WordPress-Hosting entwickelt. Schon im Januar 2017 haben wir kostenloses SSL mit Let’s Encrypt angeboten, was durch den Erfolg ein Jahr später dazu führt, dass wir für alle Webseiten „SSL erzwingen“ aktiviert haben. Wir entwickeln unsere Plattform ständig weiter und hosten sehr erfolgreich alles, was irgendwie von Linux-Servern ins Internet will: von Vereinswebseiten über Online-Shops und App-APIs bis hin zur Webseite des Marktführers für Terminhandel im Agrarbereich oder der Produktionssteuerung von Medizintechnikunternehmen.

Diese kontinuierliche Weiterentwicklung muss manchmal auch durch Anpassung unserer Leistungen, vor allem im kostenlosen Webspace, unterstützt werden. Heute machen wir einen solchen Schritt, in dem wir Änderungen an Datenbanken, E-Mail-Hosting und der Aufschaltung von Domains per DNS vornehmen. Für Kunden mit Webhosting-Paket ändert sich dabei nichts, Kunden mit kostenlosem Webspace erhalten kostenlose MySQL-Datenbanken dazu und verlieren die Möglichkeit, Domains per DNS aufzuschalten. Um einen reibungslosen Übergang zu gewährleisten werden wir die Änderungen zuerst „nicht scharf geschaltet“ aktivieren und die neuen Limits erst 14 Tage später, am 14.9.2018, aktivieren. Kunden, welche die neuen Limits überschreiten, haben also 14 Tage Zeit, um auf die Änderungen zu reagieren.

Datenbanken

Bei den Datenbanken gibt es zwei wesentliche Punkte, die sich ändern: wir stellen die Limits von Datenbank-Anzahl auf Speicherplatz-Begrenzung um, und geben in Zukunft jedem Kunden kostenlos MySQL-Speicher. Im Laufe der nächsten Wochen werden zudem auch die Anzahl der Datenbank-Benutzer unbegrenzt sein, es können dann mehrere Datenbank-Zugänge angelegt werden. Die Vorarbeiten dazu sind bereits abgeschlossen.

  • Die Anzahl der MySQL-Datenbanken ist nun unbegrenzt, dafür begrenzen wir den Speicherplatz. Kunden mit kostenlosem Webspace erhalten ein Kontingent von 500 MB MySQL-Speicherplatz. Das ist ausreichend für etwa 50 WordPress-Installationen.
  • Domains enthalten keine Inklusiv-Datenbanken mehr, da nun jeder Kunde mindestens 500 MB MySQL-Speicher besitzt.
  • Der MySQL-Speicher kann nur noch durch einen Wechsel auf ein Webhosting-Paket erhöht werden.
  • Bei Überschreitung des Speicherplatzes werden die Schreibrechte (SQL-Grants INSERT und UPDATE) entzogen, bis Speicherplatz freigegeben wird.

E-Mail

Im Bereich E-Mail-Hosting stellen wir ebenfalls von einer „unbegrenzt fair-use“-Policy auf ein Kontingent pro Kunde um. E-Mail-Speicher ist teuer und E-Mail-Hosting  relativ aufwändig und support-intensiv. Gerade im Bereich Sendungsverfolgung („meine E-Mail kommt nicht an“, eingehend oder ausgehend) und Spam-Bekämpfung müssen wir unseren Kunden relativ viel helfen, was wir refinanzieren müssen. Technischen Lösungen versprechen an der Stelle auch keine Besserung, da es sich hier meist um Verständnisprobleme und Fehlkonfigurationen von Drittservern handelt.

  • Domains enthalten nun standardmäßig 1 GB E-Mail-Speicherplatz. Die Anzahl der Postfächer bleibt weiter unbegrenzt.
  • Freespace-Kunden haben wie bisher E-Mail-Hosting nur als Inklusiv-Leistung für Domains, die bei uns gekauft werden. E-Mail-Hosting für aufgeschaltete Domains ist für Kunden mit Webhosting-Paket weiterhin möglich.
  • Kunden mit Webhosting-Paket hat schon seit einiger Zeit ein Limit von E-Mail-Speicher im Vertrag vereinbart, das nun aktiv wird.
  • Der Speicherplatz für die Postfächer teilt sich dynamisch auf die Postfächer auf. Jedes Postfach kann allen Speicher belegen, der nicht schon von E-Mails in anderen Postfächern belegt ist. Es gibt also ein Limit pro Kunde, nicht pro Postfach (die Postfächer zeigen aber ein Limit an, was sich aus dem Gesamtkontingent abzüglich der Belegung in allen anderen Postfächern berechnet).

Externe Domains aufschalten

Bei dem Aufschalten von Domains, die bei anderen Providern registriert sind, handelt es sich um die einzig neue, spürbare Einschränkung. Wenn Kunden Domains bei anderen Anbietern registrieren und dann nur unseren kostenlosen Webspace benutzen, verlieren wir gleich mehrfach:

  1. die Domain wurde nicht bei uns gekauft, der Umsatz entgeht uns,
  2. die Domain muss per DNS aufgeschaltet werden, was mehr Aufwand für den Kunden und damit zwangsläufig Support-Arbeit bedeutet,
  3. wir haben den Werbe-Effekt unserer kostenlosen Subdomains verloren, der Teil des kostenlosen Webspace ist.

Häufig sehen wir den Fall, dass unser kostenloser Webspace benutzt, die Domain woanders gekauft wird und wir dann auch noch – weil der Support des Domain-Providers miserabel ist – erklären sollen, wie die DNS-Änderung bei unserem konkurrierenden Domain-Provider funktioniert. Diesen Quersubventionierungs-Service für unsere Konkurrenten stellen wir ein 😉

Daher nehmen wir die folgenden Änderungen vor:

  • Freespace-Kunden erhalten im Gegensatz zu vorher keine Möglichkeit mehr, Domains per DNS aufzuschalten, weder für Web- noch für E-Mail-Hosting.
  • Kunden mit Webhosting-Paket können wie gewohnt Domains für Web- und E-Mail-Hosting aufschalten.
  • Bei Ablauf eines Webhosting-Pakets werden demnach auch bei Bestandskunden die aufgeschalteten Domains entfernt.

 

Um zu prüfen, ob Dein Account von einer dieser Änderungen betroffen ist, gibt es zwei Möglichkeiten:

  1. Prüfe in der Verwaltung, ob Du ein bestimmtes Limit überschreitest. Die Limits für den Speicherplatz werden auf der Startseite der Verwaltung angezeigt.
  2. Du erhälst automatisch eine E-Mail, sobald Du das Limit überschreitest oder ganz knapp vor der Überschreitung bist.

Updates KW34

In der letzten Woche ist das Update leider ausgefallen, was zum einen daran lag, dass gar nicht so viel passiert ist, zum anderen setzen wir derzeit drei größere Änderungen um. Gestern haben wir das erste Projekt so weit abgeschlossen, dass es bereit für den Merge des Pull Request ist und ein weiterer Teil schon in das Produktivsystem integriert wurde. Die Rede ist von Änderungen am Geschäftsmodell, welche die MySQL-Datenbanken, E-Mail-Hosting und Domain-Aufschaltung betreffen, und deren technischer Umsetzung. Am Mittwoch, 29.8., werden wir die Änderungen hier im Blog vorstellen und dazu auch eine Information an alle Kunden versenden.

Neben dieser nebulösen Ankündigung gibt es aber wenigstens noch ein paar wenige Punkte, die erwähnenswert sind. Im folgenden ein paar Updates:

Verwaltung:

  • Verbesserung: die Zeit zum „First Meaningful Paint“ (die Zeit, bis das erste Mal etwas sinnvolles angezeigt wird) wurde durch verschiedene Maßnahmen reduziert
  • Verbesserung: einige Kleinigkeiten wie z.B. zu breite Elemente wurden für Mobilgeräte optimiert
  • Bugfix: bei der Aufschaltung von Domains mit „aktivierten E-Mail-Services“ wurde die E-Mail-Option nicht in den zweiten Schritt übernommen, wodurch die Domain immer ohne E-Mail-Services aufgeschaltet wurde
  • Bugfix: bei Webhosting-Verträgen, welche durch neuere Verträge ersetzt wurden, wurde die Kreditkarte weiterhin belastet
  • Bugfix: für Webhosting-Kunden, welche von einem Reseller gekündigt wurden, wurde fälschlicherweise unter speziellen Umständen eine E-Mail „Dein Webhosting-Paket-Testzeitraum ist abgelaufen“ versendet
  • Bugfix: beim Transfer von .eu-Domains wurde ein falscher AuthCode als „Genereller Fehler“ und nicht als „AuthInfo falsch“ angezeigt

Infrastruktur:

  • Verbesserung: der Ordner „Junk-E-Mail“, den Outlook als Standard-Spam-Ordner verwendet, ist nun mit dem Spam-Filter „verknüpft“. E-Mails, die Outlook in diesen Ordner verschiebt werden jetzt als Spam trainiert und zukünftig serverseitig gefiltert
  • Verbesserung: wir haben die Limits der Load Balancer Queues weiter optimiert und konnten so in Burst-Situation den Fehler „429 Too Many Requests“ vollständig eliminieren

Nachtrag zum Update der Kalenderwoche 31: Die erwähnten Änderungen der Load Balancer für den Freespace (letzter Punkt unter „Infrastruktur“) erfüllen ihren Zweck deutlich besser als erwartet. Der kostenlose Webspace hat seit der Änderung eine Uptime von 99,95% oder besser! Das bekommt man bei anderen Providern nicht mal beim bezahlten Webhosting 🙂

Nächste Woche machen wir mit den Änderungen an unserem Geschäftsmodell weiter. Bis dahin erholen sich mindestens 3 Team-Mitglieder, die aus der Region sind, auf dem Broker Markt, eins der sechs großen Volksfeste in Nordwestdeutschland. Vielleicht sieht man sich ja 😉 ! Und nun bleibt mir nichts mehr übrig außer ein wunderschönes, erholsames Wochenende zu wünschen!

Updates KW 32

Endlich ist es ein wenig abgekühlt. Zum Glück nur das Wetter und nicht die Entwicklung an und bei lima-city. Wir haben gestern eine Info-Seite für unser Webhosting für Bildungsträger eingerichtet, die nun endlich mit den finalen Grafiken bestückt ist. Weitere Änderungen waren diese Woche:

Verwaltung:

  • Feature: es können nun im DNS-Manager CAA-Records angelegt werden
  • Bugfix: bei der Bestellung einer Inklusiv-Domain wurde die Fehlermeldung „Webhosting-Paket ist noch nicht bezahlt“ angezeigt, wenn der Kunde auf Rechnung zahlen kann und die Zahlung für die erste Rechnung noch nicht eingegangen ist
  • Verbesserung: versende eine E-Mail mit Hinweis auf ein Problem mit der Zahlungsmethode (gesperrte SEPA-Bankverbindung, abgelaufene Kreditkarte) oder fehlendes Guthaben 7 und 14 Tage vor der Verlängerung eines Webhosting-Pakets
  • Bugfix: bei den Cloud-VPS waren die Fallbacks für das Limit pro Monat und den Verbrauch vertauscht
  • Bugfix: beim Umzug eines Accounts zwischen Servern wurde die Datenbank-Collation nicht berücksichtigt
  • Bugfix/Verbesserung: SSH-Keys, die auf der ED25519-Kurve basieren, wurden beim Anlegen als „Key konnte nicht geparsed werden“ zurückgewiesen
  • Bugfix: für Kunden, die kein PHP-Error-Log haben wurde in der Verwaltung ein „Fehler 500“ angezeigt, jetzt wird korrekt eine leere Liste (API) bzw. eine Meldung „alles in Ordnung“ zurückgegeben

Reseller-Portal:

  • Bugfix: auf einigen Seiten wurde der Titel des Fensters nicht geändert, wenn eine neue Seite geöffnet wird (betrifft auch die Verwaltung)
  • Verbesserung: zeige den Kunden in der Domain-Liste
  • Verbesserung: bei der Anzeige einer Domain wird der Kunde angezeigt, nicht die Kundennummer
  • Verbesserung: in der Kunden-Liste wird der aktuelle Webhosting-Vertrag angezeigt, wenn der Kunde kein Reseller-Webhosting nutzt
  • Verbesserung: auf der Kunden-Detailseite wird die Details zum aktuellen Webhosting-Vertrag angezeigt, wenn der Kunde kein Reseller-Webhosting nutzt
  • Verbesserung: zeige Limits und Ressourcenverbrauch für E-Mail-Space auf der Kunden-Detailseite
  • Verbesserung: beim Erstellen eines Kunden kann direkt ein API-Key (im Kunden-Account) mit-erstellt werden. Mit dem API-Key kann der Kunden-Account per API verwaltet werden (siehe „Automation von Kunden-Verwaltung für Reseller“ und „lima-city API„)
  • Verbesserung: auf der Domain-Detailseite wird das Feld „gelöscht“ nur angezeigt, wenn die Domain gelöscht ist (anstatt „Invalid date“)

Vielen Dank an dieser Stelle an Pascal für die vielen Vorschläge!

Infrastruktur:

  • Verbesserung: Datenbank-User erhalten nun standardmäßig die  „CREATE ROUTINE“-Rechte für ihre Datenbanken

In der nächsten Woche geht es weiter mit mehr Updates am Reseller-Portal. Dort wird demnächst die Domain-Funktion dazukommen, mit der Domains zu Reseller-Konditionen registriert werden können. Wer als Agentur oder Freelancer in der Zwischenzeit eine Lösung benötigt, mit der Kunden-Accounts bei lima-city verwaltet werden können, mag sich gerne beim Support melden. Das Reseller-Portal ist dafür eine komfortable und einfach zu bedienende Lösung und das Interesse größer als wir angenommen haben.

Ansonsten wünsche ich wie immer ein schönes Wochenende und gute Erholung, bis Montag!

Updates KW 31

Die Hitze draußen lässt leider nicht nach. Im Rechenzentrum hingegen ist es schön kühl. Leider ist es darin etwas zu laut, um es aushalten zu können (man macht sich keine Vorstellung, WIE laut es im Rechenzentrum ist!). Hier ein paar Dinge, die sich diese Woche getan haben, die auch cool sind:

Verwaltung:

  • die Datenbanken-Tabelle ist nun für Mobilgeräte verbessert
  • Modale (Popups) mit Formularen darin sind in eigen Fällen beim Drücken von „Enter“ in Formularfeldern geschlossen wurden, dieser Bug ist gefixt
  • Test-Abdeckung für einige Datenbank-Tests verbessert
  • die Datenbank-Collation (=Zeichensatz) kann nun bei der Erstellung einer Datenbank angegeben werden
  • das Formular zum Ändern der PHP-Version ist nun ein API-Client (siehe API-Beschreibung im letzten Update)
  • im Cloud-VPS-Manager wurde beim Refresh (F5) der Seite in einigen Fällen ein 404 gezeigt, das Problem ist behoben
  • die Formatierung von Zahlen auf der Seite zeigt nun „?“ für eine ungültige Zahl statt den Browser-Client abstürzen zu lassen
  • die Beschreibung der E-Mail-Adresse beim „Postfach erstellen“ und „Weiterleitung erstellen“ wurde angepasst (zwischen der E-Mail-Adresse und der Domain war ein Punkt statt einem @)

Infrastruktur:

  • Bugfix/Verbesserung: wenn eine Webseite mit einem Hostnamen länger als 64 Zeichen kein SSL-Zertifikat hat, konnte das System nicht automatisch ein Zertifikat per Let’s Encrypt ausstellen, da im X509-Standard das „Common Name“-Feld nur maximal 64 Zeichen haben darf. Das Problem wurde gelöst, in dem ein Dummy-Hostname in das „Common Name“-Feld eingetragen wird und der tatsächliche Hostname als DNS-Name gesetzt wird.
  • da in der jüngsten Vergangenheit die Level7-DDoS-Angriffe auf Freespace-Websites zugenommen haben und diese aufgrund der Anzahl von Kunden je Server auch viele andere Freespace-Kunden beeinträchtigen, haben wir eine Anti-DDoS-Lösung für den kostenpflichtigen Webspace auch auf den Freespace ausgerollt. Wir beobachten, wie sich die Quality of Service dadurch verbessert.

In der nächsten Woche dürfte es einige Updates zur Reseller-Verwaltung geben. Bis dahin ein schönes Wochenende!

Updates KW 30

Es ist heiß draußen, und kaum jemand sitzt am Rechner. Zumindest kann es einem so vorkommen. Wir nutzen das Sommerloch für einige Umbauarbeiten. Heute wird das Update lang! Zuerst einige Infos zur API, dann die gewohnten Updates.

Wie schon ein paarmal angedeutet bauen wir die Verwaltung seit einiger Zeit von „normalen“ HTML-Seiten auf eine Single-Page Application (SPA) um. Diese Single-Page Application basiert auf React.js (einem Javascript-Framework) und konsumiert nur noch die API, welche wir gleichzeitig mit der OpenAPI-Spezifikation dokumentieren. Das hat unter anderem die folgenden Vorteile:

  • wir haben endlich eine vernünftige API
  • die API hat sofort mindestens einen Konsumenten und erhält dementsprechend genug Ressourcen
  • die Trennung von Frontend- und Backend-Code ist „schärfer“
  • die Entwicklung in React hat eine hohe Produktivität, Code lässt sich häufig sehr einfach wiederverwenden
  • unsere bestehenden React-Komponenten können wir theoretisch auch mit React Native für iOS und Android-Apps nutzen

Die Dokumentation der API steckt leider noch ein wenig in den Kinderschuhen – das liegt aber mehr an der Komplexität von Tools wie Swagger-UI bzw. Swagger-Codegen. Wenn es Vorschläge gibt, welches Tools eine OpenAPI 3-Spezifikation schön und komfortabel anzeigen können: bitte her damit!

Aktueller Stand der API

Derzeit sind nicht alle API-Endpunkte dokumentiert. Die Dokumentation ist teilweise deutlich aufwändiger als die API selber, wer hätte das gedacht. Der aktuelle Stand der API-Dokumentation lässt sich im OpenAPI Viewer ansehen. Die Spezifikation als JSON-Datei ist derzeit unter https://www.lima-city.de/docs/lima-city_1.0.0-oas3.json erreichbar.

Folgende Ressourcen sind derzeit dokumentiert und können per API verwaltet werden:

  • PHP-Error-Log (auslesen)
  • PHP-Version (auslesen, ändern)
  • E-Mail-Adressen und Postfächer (alles was per Verwaltung möglich ist, bis auf den Import)
  • WordPress-Seiten (alles)
  • Memcache (alles)
  • SSH-Keys (erstellen, auflisten)

Weitere Änderungen neben der API

Aber die Umbauten an der API waren nicht das einzige, was sich getan hat.

Verwaltung:

  • Verbesserung: das E-Mail-Menü ist nun vollständig auf React umgebaut
  • Verbesserung: in der Postfach-Detailansicht wird der belegte Speicherplatz und die Anzahl der E-Mails im Postfach angezeigt
  • Bugfix: wenn ein Formular abgesendet wurde und es trat ein Netzwerk-Fehler auf (Connection timed out, Network unreachable), und das Formular wurde erneut abgesendet ohne dass ein Fehler auftrat, wurde am Endes des Formulars unter dem Absenden-Button eine „0“ angezeigt
  • Bugfix: der E-Mail-Import ignoriert nun E-Mails in Spam-Ordnern. Spam-E-Mails konnten wegen eines Fehlers („Cannot APPEND to a Spam Folder“) nicht importiert werden. Nach 50 E-Mails brach imapsync den Import ab. Es sind nun keine Workarounds wie das Leeren des Spam-Ordners vor dem Import mehr nötig.

Reseller-Menü (Agenturen):

  • Bugfix: wenn ein Reseller in einen Kunden-Account wechselt und sich dann ausloggt wurde danach bis zum Löschen der Cookies auf allen Seiten ein „Fehler 404“ angezeigt
  • Bugfix: der FTP-Login war für neu angelegte Kunden nicht möglich, sofern der Kunde noch kein Passwort gesetzt hat. Jetzt ist der FTP-Login auch für Accounts, in die niemals ein Login mit Passwort stattfindet, möglich.

Infrastuktur:

  • auf der „Webseite inaktiv“-Fehlerseite wird nun die Request ID angezeigt, damit wir einfacher herausfinden können, welche Seite inaktiv ist (wenn die Fehlermeldung z.B. von einem Proxy durchgeleitet wird, der den Hostnamen verschleiert)
  • die E-Mail-Postfächer aktualisieren nun regelmäßig (alle 4 Stunden) den belegten Speicherplatz
  • die PHP-Extension XML-RPC wurde hinzugefügt
  • der Change des innodb_large_prefix und die Aktivierung der Barracuda Storage Engine in der MySQL-Konfiguration wurde umgesetzt (siehe Blog von letzter Woche, Eintrag auf der Status-Seite)

Es gab natürlich noch jede Menge anderer Änderungen. Von Verbesserungen am RAID-Monitoring für Server mit Adaptec-Controllern über Fixes bei Tests, die wegen Timings fehlschlagen (der Test dauert eine Sekunde länger als normal und schlägt fehl) bis hin zu neuen Hilfe-Seiten, Überarbeitungen in der Hilfe und Anpassungen an den und Erweiterungen der API-Rollen (siehe Update letzte Woche) ist alles dabei.

So viel zu dieser Woche, in der nächsten Woche kommt sicher einiges mehr an API-Doku, Verwaltung und Reseller-System. Wenn bis dahin Fragen, Anregungen oder Wünsche auftauchen ist der Support immer gerne dafür da. Und ich mache jetzt bis einschließlich Montag Urlaub in Berlin und besuche das PUBG Global Invitational 2018. Wer mich findet (ich trage bestimmt ein lima-city-T-Shirt oder -Sweatshirt), dem gebe ich einen aus 😉

Updates KW29

In dieser Woche überwiegen leider die unfertigen Dinge. Im git sieht man den Wald vor lauter Branch-Bäumen nicht (okay, ich lege 50 Cent in die Kasse für schlechte Wortspiele). Aber mindestens zwei große Themenbereiche, in denen sich etwas getan hat, gibt es:

Verwaltung:

  • der Zugriff von API-Keys wird nicht mehr durch einzelne Berechtigungen, sondern durch Rollen geregelt. Diese Rollen sind üblicherweise „$resource.reader“, „$resource.editor“ und „$resource.admin“, wobei $resource für alle möglichen Ressourcen stehen kann („ftp_accounts“, „mailboxes“, „cloud_vps“, etc). Die Reader-Rolle kann, wie der Name schon sagt, nur lesen, Editoren können lesen und ändern, aber nicht erstellen oder löschen. Admins haben Vollzugriff. Der Vorteil ist, dass wir die Aktionen, welche eine Rolle ausführen darf, so flexibler definieren können.
  • die API-Key-Verwaltung wurde überarbeitet
  • für API-Keys wird nun der Zeitpunkt der letzten Verwendung gespeichert
  • die Hilfe wurde um einen Artikel mit Informationen zur API ergänzt, wenngleich der Artikel ohne Liste der API-Endpoints noch ziemlich unvollständig ist (hey, Swagger…!)
  • zxcvbn.js wurde in ein separates Javascript-File verschoben, das nur geladen wird, wenn ein Passwort-Input auf der Seite angezeigt wird. Vorher wurde es immer geladen, wenn ein Passwort-Input auf der Seite vorhanden war, egal ob es angezeigt wurde oder nicht.

Reseller-Verwaltung:

  • die Webseiten-Liste gibt nun auch die PHP-Version der Webseite zurück

Webhosting:

  • auf einem Teil der MySQL-Server ist seit heute das InnoDB-File-Format „Barracuda“ testweise aktiviert (MySQL-Dokumentation). Damit werden nun auch die „COMPRESSED“- und „DYNAMIC“-Zeilen-Formate für InnoDB unterstützt. Zudem ist die Option „large prefix“ nun aktiviert. Sofern der Test in den nächsten Tagen keine Probleme aufwirft rollen wir die Änderung auf alle MySQL-Server aus. Ein Beispiel für Software, welche diese Einstellungen benötigt, ist Moodle.

Nächste Woche wird die Liste wohl um einiges länger, da wie erwähnt eine ganze Reihe von Änderungen an der Verwaltung (Datenbanken, E-Mail-Verwaltung, Zahlungsmethoden, …) momentan auf Q&A und letzten Feinschliff warten, bevor sie online gehen können. Aber dazu nächste Woche mehr. Und bis dahin wünsche ich ein schönes Wochenende!

Ältere Beiträge