Hier bei uns (und bei unseren ISP-Kunden) hat noch kein Kunde sowas gewollt. Es geht wie Du sagst nicht um Deine Wünsche sondern um die vom Kunden. Da hier noch kein Kunde so was abstruses gewollt hat und man mit dem Spamhandling (etwas, was wir können
) hier zufrieden ist, braucht man es auch -Deinen Worten nach- nicht. So einfach ist das Ganze.
Der Typ ist bitte nicht ernst zu nehmen - er hat sicher nur 3 Kunden!
LOL.
Ich bin immer noch gespannt auf die Liste.
Ich lese hier schon eine ganze weile mit. Was bist du für ein "Querulant"?
Ein vernünftiges Argument, was gegen diese Checkbox spricht, hast du bisher nicht genannt.
Und ja: auch ich finde diese Funktion äußerst sinnvoll! Und jetzt Feuer Frei!
Ja, aber wir müssen hier immer an den Endkunden denken, der es am liebsten so einfach wie möglich haben will. Gerade Kunden mit langsamen anbindungen schimpfen, wenn diese Stundenlang Backups per FTP hoch und herunterladen müssen. Das sollte künftig am besten per Klick machbar sein. (Sichern ---> bei Bedarf wiederherstellen sowie eine Löschfunktion für alte Backups)
Die werden auch vereinfacht, aber nicht über Wildcard-Zertifikate (das wäre der falsche Ansatz).
Demnächst wird man beim Anlegen von (Sub-)Domains direkt SSL aktivieren können - also in einem einzigen Workflow.
Auch gut! Da spart man sich künftig die klickerei durch hunderte Menüpunkte und vor allem aber ist es für den Endkunden wesentlich einfacher.
Alles anzeigenAls wenn es da keine Probleme gäbe...
Die Tatsache, dass man für ein SSL-Zertifikat Geld bezahlt, macht dieses per se doch nicht "besser".
Let's Encrypt bedeutet, dass der Prozess für eine Basisverschlüsselung *voll automatisiert* ist. Das wäre mir persönlich wichtiger als ein Zertifkat, bei dem ich jährlich an die Verlängerung denken muss oder von der ausstellenden CA diesbezüglich zugespammt werde.
Und wie unser gemeinsamer Freund eines (sehr empfehlenswerten) SSL-Anbieters sagt: "secure is not safe". Eine anständige Validierung (OV/EV) kostet natürlich Geld, aber vollautomatisierte DV-Zertifikate sind doch nur noch eine Gelddruckmaschine, die langsam zusammenbricht.
Auf den Punkt gebracht. KK, ich sehe wir sind uns einig und ich hoffe, dass dieser Funktion nun nichts mehr im Wege steht!
Zum Einen: Wenn ich mir anschaue, wie oft hier eine Verlängerung eines LC-Zertifikats nicht klappt und nachgearbeitet werden muss, dann setze ich ehr auf stabiles, bewährtes und gebe ein paar Cent dafür aus.
Zum Anderen: Ich kann mich argumentativ als Webhoster nicht auf der einen Seite gegen Jimdo und Konsorten sowie Geiz-ist-Geil-Kunden positionieren, die immer alles Plus noch 20% Extra obendrauf Umsonst haben wollen, wenn ich in meiner eigenen -relevanten- Umgebung noch nicht einmal 10 Euro (brutto) für ein Zertifikat ausgeben will.
Ich habe rund 3000 solcher Zertifikate im Einsatz, davon wurde bisher max. eins (1) pro Jahr (nicht Tag oder Monat) nicht verlängert... Gute Quote, oder? Warum sollte ich den kommerziellen Anbietern da noch Geld in den Rachen werfen? Außerdem ist der Aufwand bei einer größeren Serveranzahl nicht unerheblich, daher plädiere ich für eine vollautomtische Variante, siehe Pl**k, was eine Menge Zeit und Aufwand sparen würde.
Nachtrag: löscht man die IP unter Serververwaltung ---> Datenbanken ---> Zugriff erlaubt:... bleiben auch die Einträge in der Datenbank bestehen. Das sollte so nicht sein, d.h. wenn ich die IP entferne, müssen auch die entsprechenden Einträge in der Datenbank verschwinden.
Das selbe Problem habe ich auch. Die IPs werden nach einer Änderung im LiveConfig in der Datenbank nicht aktualisiert oder falls Benutzer vorhanden sind, nachgetragen. Wird es eine Lösung geben?
Alles anzeigenKann ich voll und ganz unterschreiben.
Genau das ist ja das Problem: es ist eben nicht unbedingt eine E-Mail-Adresse des LC-Kunden hinterlegt.
Was ich mir vorstellen könnte, dass wir einen Platzhalter einführen, der - falls vorhanden - durch die E-Mail-Adresse des Hauptkontaktes (oder Tech-C) ersetzt wird. Falls keiner vorhanden ist, bleibt das Feld leer. Wir müssten aber noch testen, wie sich PHP bei einem leeren sendmail_from in der php.ini verhält (ich vermute aber, dass das funktionieren müsste). Als Zwangs-Option beim sendmail_path (-f) würde das aber garantiert Probleme geben, wenn dort keine Adresse drin steht.
Das wäre ein sehr guter Lösungsansatz, um dieses seit Jahren bestehende Problem in den Griff zu bekommen. Wir hinterlegen zu jedem Kunden seit Beginn an generell auch dessen aktuelle Mailadresse - die beste Vorsaussetzung also, diese Funktion zu integrieren.
Pl*k benötigt zwangsweise von jedem Benutzer/Kunden eine E-Mail-Adresse (u.a. um dann so beliebte Mails wie "We would like to hear your opinion about Pl*k" zu schicken).
LiveConfig tut das eben nicht - in Bezug auf die DSGVO ist eine E-Mail-Adresse ein persönliches Datum, welches technisch nicht für die Erbringung der Dienstleistung (Webhosting) benötigt wird. Somit ist es prinzipiell schwer, eine Voreinstellung hierfür zu treffen.
Wer seinen Endkunden die php.ini-Einstellung sendmail_from ermöglichen möchte, kann das mit zwei Mausklicks tun: in der php.ini-Verwaltung einen neuen Eintrag "sendmail_from" anlegen, Wert dabei leer lassen, und die Änderbarbeit auf "durch Kunden" einstellen. Dann kann jeder Kunde in seinen php.ini-Einstellungen hierfür einen Wert eintragen.
Finde ich nicht gut - Kunden wollen generell so wenig wie möglich mit der Technik zu tun haben. Das sagt die Erfahrung. Die meisten verstehen gar nichts, wenn man mit solchen Begriffen um sich wirft.
Problem: der Kunde schickt per PHP-Mail Mails an irgendwelche Adressen, die zum Teil nicht erreichbar sind, z.B. Bestellbestätigungen aus Shops oder Anmeldemails usw. Diese Mails landen im Nirvana (oder besser dauerhaft in der Queue) und der normale Kunde weiß das nicht und ist im glauben, das die Mail an eine gültige Adresse verschickt worden ist.
Gäbe es ansonsten bei "sendmail_from" einen Platzhalter der Mailadresse, die bei LC für den jeweiligen Kunden hinterlegt ist?
Ein Workaround ist ja bereits beschrieben (Reverse Proxy) - wir arbeiten aber an einer eleganteren Lösung.
Danke, hierüber werden sich alle Nutzer neben meiner wenigkeit sehr freuen!
Nebenbei. Man darf von einem LC-Betreibr schon erwarten, das er ein echtes Zertifikat verwendet.
Begründung?
Danke, das mit den 40 Subdomains war nur ein Beispiel. Es gibt Großkunden mit hunderten Subdomains, hier ist der Aufwand natürlich enorm, insbesondere wenn ständig neue Subdomains hinzukommen oder alte gelöscht werden. Diese Prozesse könnten künftig wesentlich vereinfacht werden.
Bei Plesk ist das mit einem Klick erledigt. Warum ist das hier so umständlich? Für mich ist das ganze nur eine halbherzige Not-Lösung.
Gar keine Antwort seit über einem Monat? Hallo Support?
Wann wird es möglich sein, Wildcard-Zertifikate durch LiveConfig ausstellen zu lassen? Der manuelle Aufwand bei 40 Subdomains ist enorm! Mit Plesk soll dies bereits möglich sein, habe ich gehört.
Danke für die Antworten, aber eine einfache Lösung über die Benutzeroberfläche wäre mir - wie sicher allen anderen auch - am liebsten.
LC Business. Dann gibt es einen Login für alle.
Ansonsten als Übergangslösung: Subdomain als Proxy anlegen und diese über Let's Encrypt absichern. Klappt wunderbar.
Die sichert aber nicht die Benutzeroberfläche selbst ab, oder? Dafür braucht man doch nach wie vor ein gekauftes Zertifikat, oder sehe ich das falsch?
Die Sache sollte in der tat vereinfacht werden, vollste zustimmung!
Bisher ist es extrem zeitaufwendig, wenn man einen Kunden und dessen Datenbanken, Mailadressen, Cronjobs... usw. manuell auf einen anderen Server verschieben muss. Hier sollte es eine Lösung geben, z.B. eine Exportdatei aller Daten, welche man auf einem anderen beliebigen LiveConfig-Server wieder importieren kann. Bei einem Kunden mit 53 Mailadressen, 16 Datenbanken, 8 Cronjobs... sind locker ein paar Stunden verbraucht bis alles wieder so angelegt worden ist, wie auf dem Ursprungs-Server.
Sämtliche Kundenseiten kann man problemlos mit Let's Encrypt absichern, ein Lob für diese Funktion. Nur den eigenen Server nicht, hier muss noch ein Zertifikat gekauft werden, man wirft den Vergabestellen unnötiges Geld hinterher und der manuelle Aufwand ist enorm groß, wenn ein Zertifikat auf über 70 Servern abgelaufen ist und ersetzt werden muss. Allein dafür ist ein halber Tag weg.
Bei z.B. Plesk kann man für den eigenen Server problemlos ein Zertifikat erstellen, welches dann für den Mailserver, FTP und den Login genutzt wird und sich von allein verlängert.
