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!