Ist eine Arbeitswoche wirklich so kurz oder kommt mir das nur so vor? Jedenfalls ist schon wieder Freitag, und damit Zeit für das wöchentliche Update aus dem Maschinenraum.
Während ich hier schreibe läuft gerade die neue Verwaltung für Datenbank-User durch den Build-Server. Sofern alle Tests für den Build Nr. 1481 grün sind, wird der Build-Server die Änderung gleich ausrollen. Bevor ich auf die neue Datenbank-Verwaltung eingehe gibt es aber noch einige kleinere Punkte, die ich vorher abreißen möchte:
Software-Installer:
- Bugfix: der Software-Installer hat für einige Softwares keinen Namen im Verzeichnis eingefügt (statt „nextcloud-2018-09-21-abc“ hieß das Verzeichnis „-2018-09-21-abc“)
- Verbesserung: nextCloud wird nun „vollständig“ vom Software-Installer installiert, die Einrichtung des Admin-Accounts und der Datenbank-Zugangsdaten erledigt nun der Software-Installer
- Bugfix: das Auto-Update der WordPress-Software-Pakete (Deutsch und International) hat zwar die Version der Software geändert, dabei aber die neue Archiv-URL wieder überschrieben, so dass weiter das alte ZIP-File verwendet wurde.
- Bugfix: bei Softwares, welche keine MySQL-Datenbank benötigen, wurde versucht, einen neuen Datenbank-Nutzer zu erzeugen, was zu einem Abbruch der Installation führte
Verwaltung:
- Bugfix: ein Fehler 500/Server-Fehler bei den PHP-Error-Logs wurde behoben, wenn das Log Zeichen in unterschiedlichen Encodings enthält
- Verbesserung: die Meldung „es existiert bereits ein Postfach mit dieser E-Mail-Adresse“ beim Anlegen einer E-Mail-Weiterleitung wurde erweitert auf „es existiert bereits ein Postfach mit dieser Adresse, bitte lösche das bestehende Postfach oder erstelle im Postfach einen Filter, welcher die E-Mails weiterleitet“
- Wartung: weiterer, alter Code zu Datenbank-Test-Accounts entfernt
- Bugfix: das Löschen einer Datenbank führte zu einem Fehler, sofern individuelle Rechte für die Datenbank vergeben wurden
- Verbesserung: die Test-Abdeckung für das Live-Schalten von WordPress-Staging-Seiten wurde verbessert, dabei wurde ein Bug gefunden und behoben
Domain-Check, Bestellung & Sonstige:
- Bugfix: beim Prüfen von Domains mit Subdomain im Domain-Check (z.B. foobar.lima-city.de) konnte ein Fehler beim Abrufen von Premium-Domain-Preisen auftreten
- Bugfix: beim Bestellen von Inklusiv-Domains für einen Webhosting-Vertrag, welcher noch nicht erstmalig abgerechnet wurde, aber bereits gebucht ist und bei dem eine Kreditkarte als Zahlungsmethode hinterlegt wurde, wird nun beim Blockieren des Betrags auf der Kreditkarte kein Fehler mehr angezeigt
- Verbesserung: das Aktualisieren von Kunden-Konfiguration auf den Frontend- und Backend-Servern wurde verbessert, es werden weniger unnötige Updates gemacht
- Bugfix: beim Aktivieren des Wartungsmodus für MySQL-User (temporäre Login-Sperre, z.B. beim Umzug eines Accounts zwischen Servern) wurden auch User auf dem gleichen Server gesperrt, wenn sie das selbe Präfix hatten (z.B. Sperre für USER1 konnte USER12, USER123 etc. deaktivieren). Alle betroffen Accounts wurden wieder aktiviert.
Wenn ich mir die Liste ansehe, sind es doch deutlich mehr Kleinigkeiten, als ich dachte. Da hat sich einiges bewegt – aber kommen wir nun zum großen Update!
Verwaltung für Datenbank-Benutzer
In der Verwaltung unter „MySQL-Datenbanken“ ist nun eine Navigation für den Wechsel zwischen Datenbanken und Datenbank-Benutzern vorhanden. Bis zum Release des neuen Verwaltung-Layouts ist das eine Übergangslösung, um nicht einen weiteren Menüpunkt in die schon jetzt überladene Navigation zu setzen.
Die folgende Bildergalerie zeigt einen kleinen Rundgang durch die neue Datenbank-Benutzer-Verwaltung:
-
- Die Übersichts-Liste aller Datenbank-Benutzer
-
- die Zugangsdaten eines Datenbank-Benutzers anzeigen
-
- Benutzer mit Rechten im „einfachen Modus“
-
- Beim Erstellen einer Datenbank kann direkt ein neuer Datenbank-Benutzer angelegt werden
-
- Sofern Benutzerdefinierte Rechte vergeben sind, können sie hier angezeigt werden
-
- Die benutzerdefinierten Rechte sind ebenfalls änderbar
Datenbank-Benutzer haben zwei Modi, in denen ihre Rechte verwaltet werden können:
- einfacher Modus: es werden Rechte für alle Datenbanken vergeben, dabei gibt es vier Abstufungen (Admin, Readonly, Readwrite, keine Rechte). „Keine Rechte“ ist eigentlich nur für Monitoring-Scripts erforderlich, welche die Server-Verfügbarkeit prüfen
- komplexer Modus: für jede Datenbank werden die Rechte (Grants) individuell vergeben (siehe Screenshot 5 und 6)
Beim Anlegen einer Datenbank gibt es eine ähnliche Auswahl für die Rechte des neuen Benutzers. Hier wird – genauso wie vom Software-Installer, wenn dieser eine neue Datenbank anlegt – ein Benutzer mit Rechten im komplexen Modus angelegt, welcher nur Zugriff auf die neue Datenbank erzeugt.
Wie immer versuchen wir die Verwaltung möglichst verständlich aufzubauen, deshalb möchte ich dazu gar nicht mehr so viel schreiben, sondern lieber mehr Feedback erhalten 🙂 Wer also Fragen oder Anregungen hat, Probleme findet oder Verbesserungsvorschläge weiß: immer her damit! Schreibe uns einen Kommentar, eine E-Mail, eine Nachricht auf Twitter, oder was auch immer!
Ansonsten bleibt mir nichts übrig, außer ein schönes Wochenende zu wünschen!
Warum wurde denn die Funktion zum ANZEIGEN des Passworts entfernt? Könnt Ihr diese wieder implementieren, da sich sicher – so wie wir – niemand das Passwort notiert hat und nun bei fast 20 Anwendungen das neue Passwort einpflegen muss, nachdem er zwangsweise das DB Passwort geändert hat.
Grüße!
Hallo Manuel, dazu haben wir auch schon was im vorherigen Blogpost geschrieben (unter „Warum werden MySQL-Passwörter nicht mehr angezeigt?“): https://blog.lima-city.de/2018/09/updates-kw37/
Was hälst Du davon?
Ich verstehe die Anmerkung von Manuel nicht. „zwangsweise das DB Passwort geändert“- wer hat das denn getan. Ich habe bei meinen DBs kein Problem und im Zweifelsfall steht ja das PW in der config.php der jeweiligen Anwendung.
Hey Paul,
das ist absolut richtig. Wir haben die Datenbank-Passwörter nicht geändert, wir haben nur die bestehenden Klartext-Passwörter verschlüsselt, aber sie sonst nicht angefasst. Wäre ja auch super-dumm, wenn wir die Passwörter ändern würden und einfach jedem Kunden seine Webseite zerschießen 😉
Da müssten wir ja auch allen Kunden ihre Monats-Rechnung erstatten (Verfügbarkeitsgarantie). Von daher ist es recht unwahrscheinlich, dass wir das mal eben so machen 😀
Hallo Allerseits,
ich verstehe eure Ansicht. Ich habe insgesamt 3 Anwendungen installiert, die MySQL verwendet und bei diesen stehen die Passwörter nicht im Klartext in der config. Habe dort ein „password=encrypted:XXX“.
Dass LC keine Passwörter ändert, weiß ich selber. Wäre für mich auch ein Grund mir sofort einen anderen Hoster zu suchen. Das Passwort „zwangsweise ändern“ dürfen nun Kunden wie ich, die die Passwörter nicht mehr im Klartext haben.
Grüße!
(an die die sich beschweren weil die passwörter nicht mehr klar sind) also hättet ihr das lieber das sie in Klartext da stehen und von jedem browser addon gelesen werden können oder falls die Lima datenbank gehackt wird das die sofort auf eure zugriff haben? :3
(und es ist unwarscheinlich das die eigene Lima DB auf dem selben server läuft wie die Nutzer DBs)
und da die anwendungen welche das passwort verschlüsselt haben das passwort irgendwie nutzen müssen gibt es da ein weg diese zu entschlüsseln (man muss nur im source code schauen wie und wo)
Hey Justin,
ja und nein. Passwörter lassen sich nicht wieder „entschlüsseln“ (zumindest wenn man es richtig macht nicht), weil sie gar nicht verschlüsselt sondern gehasht werden https://de.wikipedia.org/wiki/Kryptographische_Hashfunktion#).
Entschlüsseln gibt’s also nicht.